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The  Department  of  Defense  High  Order  Language  Commonality  program 
began  in  1975  with  the  goal  of  establishing  a single  high  order 
computer  programming  language  appropriate  for  DoD  embedded  computer 
systems.  This  effort  has  been  characterized  by  extensive  coopera- 
tion with  the  European  Community  ar.d  NATO  countries  have  been 
involved  in  every  aspect  of  the  work.  < The  requirements  have  been 
distributed  worldwide  for  comment  through  the  military  and  civil 
communities,  producing  successively  more  refined  versions.  Formal 
evaluations  were  performed  on  dozens  of  existing  languages  conclud- 
ing that  a single  language  meeting  these  requirements  was  both 
feasible  and  desirable.  Such  a language  has  now  been  developed. 

i 

I wish  to  encourage  your  support  and  participation  in  this  effort, 
and  I submit  the  design  of  this  language  for  your  review  and  comment. 
Such  comments  and  detailed  justified  change  proposals  should  be  for- 
warded to  HOLWG,  DARPA,  1400  Wilson  Boulevard,  Arlington,  VA  22209 
by  30  November  1979.  The  language,  as  amended  by  such  response, 
will  become  a Defense  standard  in  early  1980.  Before  that,  changes 
will  be  made;  after  that,  we  expect  that  change  will  be  minimal. 

Beginning  in  May  1979,  the  effort  will  concentrate  on  the  technical 
test  and  evaluation  of  the  language,  development  of  compilers  and 
programming  tools,  and  a capability  for  controlling  the  language  and 
validating  compilers.  The  requirements  and  expectations  for  the 
environment  and  the  control  of  the  language  are  being  addressed  in 
a series  of  documents  already  available  to  which  comment  is  also 
invited.  We  intend  that  Government-funded  compilers  and  tools  will 
be  widely  and  cheaply  available  to  help  promote  use  of  the  language. 

Ada  has  been  chosen  as  the  n’ame  for  the  common  language,  honoring 
Ada  Augusta,  Lady  Lovelace,  the  daughter  of  the  poet.  Lord  Byron, 
and  Babbage's  programmer. 
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The  Green  language  is  the  result  of  a collective  effort  to  design 
a language  satisfying  the  Steelman  requirements.  The  design 
team  was  led  by  Jean  D.  Ichbiah  and  has  included  Bernd  Krieg- 
Brueckner,  Brian  A.  Wichmann,  Henry  F.  Ledgard,  Jean-Claude 
Heliard,  Jean-Raymond  Abrial,  John  G.P.  Barnes,  and  Olivier 
Roubine.  In  addition,  major  contributions  were  provided  by  G. 
Ferran,  i.C.  Pyle,  SA  Schuman,  and  S.C.  Vestal. 

Two  parallel  efforts  started  in  the  second  phase  of  this  design 
had  a deep  influence  on  the  language.  One  was  the  design  of  a 
test  translator,  with  the  participation  of  K.  Ripken.  P.  B outlier, 
J.F.  Hueras,  and  R.G.  Lange.  The  other  was  the  development  of 
a formal  definition  using  denotational  semantics,  with  the  par- 
ticipation of  V.  Donzeau-Gouge,  G.  Kahn,  and  B.  Lang.  The 
entire  effort  benefitted  from  the  dedicated  support  of  Lyn 
Churchill  and  W.L.  Heimerdinger. 

At  various  stages  of  this  project  several  persons  had  a con- 
structive influence  with  their  comments,  criticisms  and  sugges- 
tions. They  are  P.  Brinch  Hansen.  DA.  Fisher.  G.  Goos.  CA.R. 
Hoare.  M.  Woodger,  and  Mark  Rain. 

Over  the  two  years  spent  on  this  project,  three  intense  one- 
week  design  reviews  were  conducted  with  the  participation  of 
J.B.  Goodenough,  H.  Harte,  M.  Kronental,  K.  Correll,  R.  Firth, 
A.N.  Habermann,  J.  Teller,  P.  Wegner,  and  P.  R.  Wetherall. 

These  reviews,  other  comments  by  E.  Boebert.  P.  Bonnard,  T. 
Frogatt,  H.  Ganzinger,  C.  Hewitt,  J.L.  Mansion,  F.  Mine I,  E. 
Morel.  J.  Roehrich,  A.  Singer.  0.  Slosberg,  and  I.C.  Wand;  the 
numerous  evaluation  reports  received  on  the  preliminary 
design,  the  on-going  work  of  the  IFIP  Working  Group  2.4  on 
system  implementation  languages,  and  that  of  LTPL-E  of  Pur- 
due Europe,  all  had  a decisive  influence  on  the  final  shape  of 
the  Green  language. 
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1.  Introduction 


This  report  describes  the  Green  programming  language,  designed  in  accordance  with  the 
Steelman  requirements  of  the  United  States  Department  of  Defense.  Overall,  the  Steelman 
requirements  call  for  a language  with  considerable  expressive  power  covering  a wide  application 
domain.  As  a result  the  language  includes  facilities  offered  by  classical  languages  such  as  Pascal 
as  well  as  facilities  often  found  only  in  specialized  languages.  Thus  the  language  is  a modern 
algorithmic  language  with  the  usual  control  structures,  and  the  ability  to  define  types  and  sub- 
programs. It  also  serves  the  need  for  modularity,  whereby  data,  types,  and  subprograms  can  be 
packaged.  It  treats  modularity  in  the  physical  sense  as  well,  with  a facility  to  support  separate 
compilation. 

In  addition  to  these  classical  aspects,  the  language  covers  real  time  programming,  with  facilities  to 
model  parallel  tasks  and  to  handle  exceptions.  It  also  covers  systems  program  applications.  This 
requires  access  to  system  dependent  parameters  and  precise  control  over  the  representation  of 
data.  Finally,  both  application  level  and  machine  level  input-output  are  defined. 


1.1  Design  Goals 


The  Green  language  was  designed  with  three  overriding  concerns:  a recognition  of  the  importance 
of  program  reliability  and  maintenance,  a concern  for  programming  as  a human  activity,  and 
efficiency. 

The  need  for  languages  that  promote  reliability  and  simplify  maintenance  is  well  established. 
Hence  emphasis  was  placed  on  program  readability  over  ease  of  writing.  For  example,  the  Green 
language  requires  that  program  variables  be  explicitly  declared  and  that  their  type  be  specified. 
Automatic  type  conversion  is  prohibited.  As  a result,  compilers  can  ensure  that  the  types  of  objects 
satisfy  their  intended  use.  Furthermore,  error  prone  notations  have  been  avoided,  and  the  language 
syntax  avoids  the  use  of  encoded  forms  in  favor  of  more  English-like  constructs.  Finally,  the 
language  offers  support  lor  separate  compilation  of  program  units  in  a way  that  facilitates  program 
development  and  maintenance,  and  which  provides  the  same  degree  of  checking  as  within  a unit. 

Concern  for  the  human  programmer  was  also  stressed  during  the  design.  Above  all,  an  attempt 
was  made  to  keep  the  language  as  small  as  possible,  given  the  ambitious  nature  of  the  application 
domain.  We  have  attempted  to  cover  this  domain  with  a minimum  number  of  underlying  concepts 
integrated  in  a consistent  and  systematic  way.  Nevertheless  we  have  tried  to  avoid  the  pitfalls  of 
excessive  involution,  and  in  the  constant  search  for  simpler  designs  we  have  tried  to  provide 
language  constructs  with  an  intuitive  mapping  on  what  the  user  will  normally  expect. 

No  language  can  avoid  the  problem  of  efficiency.  Languages  that  require  overly  elaborate  com- 
pilers or  that  lead  to  the  inefficient  use  of  storage  or  execution  time  force  these  inefficiencies  on  all 
machines  and  on  all  programs.  Every  construct  in  the  Green  language  was  examined  in  the  light  of 
present  implementation  techniques.  Any  proposed  construct  whose  implementation  was  unclear 
or  required  excessive  machine  resources  was  rejected. 


Perhaps  most  importantly,  none  of  the  above  goals  was  considered  something  that  could  b( 
achieved  after  the  fact.  The  design  goals  drove  the  entire  design  process  from  the  beginning. 


1 .2  Language  Summary 


A program  in  the  Green  language  is  a sequence  of  higher  level  program  units,  which  can  be  com- 
piled separately.  Program  units  may  be  subprograms  (which  define  executable  algorithms), 
package  modules  (which  define  collections  of  entities)  or  task  modules  (which  define  concurrent 
computations).  The  facility  for  separate  compilation  allows  a program  to  be  designed,  written,  and 
tested  in  largely  independent  parts.  This  facility  is  especially  useful  for  large  programs  and  the 
creation  of  libraries. 

Program  Units 

A subprogram  is  the  basic  unit  for  expressing  an  algorithm.  A subprogram  can  have  parameters, 
which  specify  its  connections  to  other  program  units.  The  Green  language  distinguishes  two  kinds 
of  subprograms:  procedures  and  functions. 

A procedure  subprogram  is  the  logical  counterpart  to  a series  of  actions.  For  example,  it  may  read 
in  data,  update  variables,  or  produce  some  output.  A function  subprogram  is  the  logical  counter- 
part to  a mathematical  function  for  computing  a value;  unlike  a procedure,  a function  can  have  no 
side  effects.  Value  returning  procedures  are  also  allowed. 

A package  module  is  the  basic  unit  for  defining  a collection  of  logically  related  entities.  For  exam- 
ple. packages  can  be  used  to  define  a common  pool  of  data  and  types,  a collection  of  related  sub- 
programs. or  encapsulated  types  with  associated  operations.  Portions  of  a package  can  be  hidden 
from  the  user,  thus  allowing  access  only  to  the  logical  properties  expressed  by  the  package 
module. 

A task  module  is  similar  to  a package  module,  but  with  additional  capabilities  for  parallel  process- 
ing. Tasks  may  be  implemented  on  multiple  processors  or  with  interleaved  execution  on  a single 
processor.  Synchronization  is  achieved  by  entries  which  are  called  like  procedures  but  are 
executed  in  mutual  exclusion.  Like  procedures,  entries  can  contain  parameters  specifying  the  tran- 
smission of  data  between  tasks. 

Declarations  and  Statements 

Each  program  unit  generally  contains  two  parts:  a declarative  part,  which  defines  the  logical 
entities  to  be  used  in  the  program  unit,  and  a sequence  of  statements,  which  define  the  execution 
of  the  program  unit. 

The  declarative  part  associates  names  with  declared  entities.  A name  may  deno’e  a type,  a cons- 
tant, or  a variable.  A declarative  part  also  introduces  the  names  and  parameters  of  other  sub- 
programs. task  modules,  and  package  modules  to  be  used  in  the  program  unit. 

Statements  describe  actions  to  be  performed.  An  assignment  statement  specifies  that  the  current 
value  of  a variable  is  to  be  replaced  by  a new  value.  A subprogram  call  statement  invokes  execu- 
tion of  a subprogram,  after  associating  sny  arguments  provided  at  the  call  with  the  corresponding 
formal  parameters  of  the  subprogram. 

If  and  case  statements  allow  the  selection  of  an  enclosed  sequence  of  statements  based  on  the 
value  of  a condition  or  expression  at  the  head  of  the  statement. 
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The  basic  iterative  mechanism  in  the  language  is  the  loop  statement  A loop  statement  specifies 
that  a sequence  of  statements  is  to  be  executed  repeatedly  until  an  iteration  specification  is  com 
pleted  or  an  exit  statement  is  encountered 

Certain  statements  are  only  applicable  to  tasks.  An  initiate  statement  specifies  that  one  or  more 
tasks  may  begin  execution  concurrently  with  the  initiating  task  An  entry  call,  which  appears  as  a 
normal  subprogram  call,  specifies  that  a task  is  ready  for  a rendezvous  with  another  task  contain- 
ing the  declaration  of  the  entry.  An  accept  statement  within  the  other  task  specifies  the  actions  (if 
any)  to  be  executed  when  the  corresponding  entry  is  called  Afw  the  rendezvous  is  completed, 
both  the  calling  task  and  the  task  containing  the  entry  may  continue  their  execution  in  parallel  A 
select  statement  allows  a selective  wait  for  one  of  several  alternative  rendezvous. 

Execution  of  a program  unit  may  lead  to  exceptional  situations  in  which  normal  program  execution 
cannot  continue  For  example,  an  arithmetic  computation  may  exceed  the  maximum  allowed  value 
of  a number,  or  an  attempt  may  be  made  to  access  the  value  of  an  uninitialized  variable.  To  deal 
with  these  situations,  the  statements  of  a program  unit  can  be  textually  followed  by  exception 
handlers  describing  the  actions  to  be  taken  when  the  exceptional  situation  arises. 

Data  Types 

Every  object  in  the  language  has  a type,  which  defines  its  logical  properties  and  the  operations  that 
can  be  performed  on  objects  of  the  type.  There  are  four  basic  classes  of  types:  scaler  types,  com- 
posite types,  access  types,  and  private  types 

The  scalar  types  INTEGER.  BOOLEAN,  and  CHARACTER  are  predefined  Integer  types  provide  a 
means  of  performing  exact  numerical  computation.  Approximate  computation  can  be  performed 
using  floating  point  tyoes  (with  a relative  bound  on  the  error)  or  using  fixed  point  types  (with  an 
absolute  bound  on  the  error).  Enumeration  types  provide  a means  for  users  to  define  problem 
dependent  types  with  discrete  values.  Character  sets  can  be  defined  as  enumeration  types. 

Composite  types  allow  definitions  of  structured  objects  with  related  components  The  composite 
types  in  the  language  provide  for  arrays  and  records.  An  array  is  an  object  with  indexed  compo- 
nents of  the  same  type  A record  is  an  object  with  named  components  of  possibly  different  types. 
Alternative  record  structures  can  be  defined  by  having  a variant  part  within  t record  type. 

Access  types  allow  the  construction  of  complex  data  structures  that  are  created  dynamically  Both 
the  elements  in  the  structure  and  their  relation  to  other  elements  can  be  altered  during  program 
execution.  / 

Private  types  can  be  defined  in  a package  module  that  hides  irrelevant  structural  details  Only  the 
logically  necessary  properties  are  made  visible  to  a user. 

The  concept  of  a type  is  refined  with  the  concept  of  a subtype  whereby  a user  can  constrain  the 
set  of  allowed  values  in  a type.  Subtypes  can  be  used  to  define  subranges  of  scalar  types,  arrays 
with  a limited  set  of  index  values,  and  records  with  a particular  variant. 

Other  Facilities 

Representation  specifications  can  be  used  to  specify  the  mapping  between  data  types  and  features 
of  an  underlying  machine.  For  example,  the  user  can  specify  that  an  array  is  to  be  represented  in 
packed  form,  that  objects  of  a given  type  must  be  represented  with  a specified  number  of  bits,  or 
that  the  components  of  a record  are  to  be  represented  in  a specified  storage  layout. 
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Finally  the  language  includes  facilities  for  separate  compilation,  generic  (that  is,  parameterueu 
program  units  ana  noth  user  level  and  machine  level  input-output. 


1.3  Sources 


A continual  difficulty  in  language  design  is  that  one  must  both  identify  the  capabilities  required  by 
the  application  domain  and  design  language  features  that  provide  these  capabilities. 

The  difficulty  existed  in  this  design,  although  to  a much  lesser  degree  than  usual  because  of  the 
Steelman  requirements.  These  requirements  often  simplified  the  design  process  by  permitting  us 
to  concentrate  on  the  design  of  a given  system  satisfying  a well  defined  set  of  capabilities,  rathei 
than  on  the  definition  of  the  capabilities  themselves. 

Another  significant  simplification  of  our  design  work  resulted  from  earlier  experience  acquired  by 
several  successful  Pascal  derivatives  developed  with  similar  goals.  These  are  the  languages  Euclid, 
Lis  Mesa  Modula  and  Sue  Many  of  the  key  ideas  and  syntactic  forms  developed  in  these 
languages  have  a counterpart  in  the  Green  language  We  may  say  that  whereas  these  previous 
designs  could  be  considered  as  genuine  research  efforts,  the  Green  language  is  the  result  of  a pro- 
iect  in  language  design  engineering,  in  an  attempt  to  develop  a product  that  represents  the  current 
state  of  the  art 

Several  existing  languages  such  as  Algol  68  and  Simula  and  also  recent  research  languages  such 
as  Aiphard  and  Clu,  influenced  this  language  in  several  respects,  although  to  a lesser  degree  than 
the  Pascal  family 

Finally,  the  evaluation  reports  on  the  initial  formulation  of  Green,  the  other  language  p.oposals. 
and  the  general  reviews  had  a significant  effect  on  the  language. 


1 .4  Syntax  Notation 

The  context-free  syntax  of  the  language  is  described  using  a simple  variant  of  Backus-Naur  Form. 
In  particular, 

(a)  Lower  case  words,  some  containing  embedded  underscores,  denote  syntactic  categories  for 
example 

adding_operator  " 

(b)  Boldface  words  denote  reserved  words,  for  example 

array 

(c)  Square  brackets  enclose  optional  items,  for  example 

and  loop  [identifier!; 
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(d)  Braces  enclose  a repeated  item.  The  item  may  appear  zero  or  more  times.  Thus  an  identifier 
list  is  defined  by 

identifierjist  ::=  identifier  |.  identifier) 

(e)  Any  syntactic  category  prefixed  by  an  italicized  word  and  an  underscore  is  equivalent  to  the 
unprefixed  corresponding  category  name.  The  prefix  is  intended  to  convey  some  semantic 
information.  For  example 

fype_name  r«s*_name 

are  both  equivalent  to  the  category 

name 

In  addition,  the  syntax  rules  describing  structured  constructs  are  presented  in  a form  that  corres- 
ponds to  the  preferred  paragraphing.  For  example,  an  if  statement  is  defined  as 

if_statement  ::= 

if  condition  then 
sequence_of_statements 
letsN  condition  then 
sequence_of_statements| 

sequence_of_statementsJ 

end  If: 
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2.  Lexical  Elements 


This  chapter  defines  the  lexical  elements  of  the  language. 


2.1  Character  Sat 

All  language  constructs  may  be  represented  with  a basic  character  set.  which  is  subdivided  as  fol- 
lows: 

(a)  Upper  case  letters 

ABCDEFGHIJKIMNOPQRSTUVWXY2 

(b)  Digits 

0123456789 

(c)  Special  characters 
"#&'()♦  + 

(d)  The  space  character 

An  extended  character  set.  for  example  one  including  the  following  additional  ASCII  characters, 
may  be  used  in  programs: 

(e)  Lower  case  letters 

abcdefghijklmnopqrstuvwxyz 

(f)  Other  special  characters 

' $ % ? @ l \ I ‘ ' I t ~ 

Every  program  may  be  converted  into  an  equivalent  program  using  only  the  basic  character  set.  A 
lower  case  letter  is  equivalent  to  the  corresponding  upper  case  letter,  except  within  character  str- 
ings; rules  for  conversion  of  strings  into  the  basic  character  set  appear  in  section  2.5. 

In  addition,  the  following  replacements  are  always  allowed  for  characters  that  may  not  be 
available: 

• the  vertical  bar  character  | is  equivalent  to  the  exclamation  mark  I as  a delimiter  between 
choices  (e.g.  see  3.6.2).  Note  that  on  some  terminals,  the  vertical  bar  appears  as  a broken  ver- 
tical bar. 

• the  double  quote  character  ” is  equivalent  to  a % character  as  a string  bracket 

• the  sharp  character  0 is  equivalent  to  the  colon  : in  a based  number 


2.2  Lexical  Units  and  Spacing  Convention* 

The  lexical  units  of  a program  are  identifiers  (including  reserved  words),  numbers,  strings,  and 
delimiters.  A delimiter  is  either  one  of  the  following  special  characters  in  the  basic  character  set 

or  one  of  the  following  compound  symbols 

=>  ..  **  :=  =::=:/=  >=  <=  <<  >> 

Spaces  may  be  inserted  freely  with  no  effect  on  meaning  between  lexical  units.  At  least  one  space 
must  separate  adjacent  identifiers  or  numbers.  Besides  terminating  a comment,  the  end  of  each 
line  is  equivalent  to  a space.  Thus  each  lexical  unit  must  fit  on  one  line. 

2.3  Identifiers 

Identifiers  are  used  as  names.  Isolated  underscore  characters  may  be  included  and  all  characters 
are  significant,  including  underscores. 

identifier 

letter  ||underscore|  letter_or_digit) 
letter_or_digit  ::=  letter  | digit 
letter  ::  upper_caseJetter  | lower  _case_letter 

Note  that  identifiers  differing  only  in  the  use  of  corresponding  upper  and  lower  case  letters  are 
considered  as  the  same. 

Examples. 

COUNT  X get.  symbol  Ethelyn 

SNOBOL.4  XI  page.count  STORE-NEXT  JTEM 

2.4  Number* 

There  are  two  classes  of  numbers:  integers  for  exact  computation,  and  real  numbers  for  approx- 
imate computation.  Their  explicit  representation  is  given  here. 

number  ::  integer_number  | approximate-number 

integer  number  integer  | based-integer 


integer  : digit  | (underscore I digit) 


based-integer  ::= 

base  # extended_digit  ([underscore I extended-digit  I 

base  integer 

extended-digit  digit  | letter 

approximate-number 

integer. integer  |E  exponent) 

| integer  E exponent 

exponent  ::=  l + | integer  | - integer 

Isolated  underscore  characters  may  be  inserted  between  adjacent  digits  or  extended  digits  of  a 
number,  but  are  not  significant.  Spaces  may  not  appear  within  numbers. 

Based  integers  can  be  represented  with  any  base  from  2 to  16.  For  bases  above  ten,  digits  may 
include  the  letters  A through  F with  the  conventional  meaning  10  through  15. 


Examples'. 

12  0 123-456 

2#101 1-0101  16#FFFF 
12.0  0.0  0.456  10-000.1 

1E6  1.0E-6  3 14e  + 3 


— integers 

— based  integers,  values  181  and  65535 

— approximate  numbers 

— approximate  numbers  with  exponent 


2.5  Character  Strings 

A character  string  is  a sequence  of  zero  or  more  characters  prefixed  and  terminated  by  the  string 
bracket  character  (the  double  quote  " or  its  replacement  the  % character). 

cha'acte*_string  ::=  “ (character) 

In  order  that  arbitrary  strings  of  characters  may  be  represented,  any  included  string  bracket 
character  must  be  written  twice.  The  length  of  a string  is  the  length  of  the  sequence  represented. 
Strings  of  length  one  are  also  used  for  literals  ot  character  types  (see  3.5.1).  Strings  longer  than 
one  line  must  be  represented  using  catenation. 


Examples: 


""  - an  empty  string 

•'*"  "A — three  one-character  literals  * A 

"characters  such  as  $.  I and  | may  appear  in  strings" 

"FIRST  PART  OF  A STRING  THAT  " 8. 

"CONTINUES  ON  THE  NEXT  LINE" 
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A character  string  may  contain  characters  not  in  the  basic  character  set  A string  containing  such 
characters  can  be  converted  to  3 string  written  with  the  basic  character  set  by  using  identifiers 
denoting  these  characters  in  catenated  strings.  Such  identifiers  are  defined  in  the  predefined 
environment  Thus  the  string  "ABSCD"  could  be  written  as  "AB'  & DOLLAR  & "CD".  Similarly,  the 
string  ' ABcd  with  lower  case  letters  could  be  written  as  AB"  & LC_C  & LC_D. 


2.0  Comments 


A comment  starts  with  a double  hyphen  and  is  terminated  by  the  end  of  the  line.  It  may  only 
appear  following  a lexical  unit  or  at  the  beginning  or  end  of  a program  unit.  Comments  have  no 
effect  on  the  meaning  of  a program;  their  sole  purpose  is  the  enlightenment  of  the  human  reader 

Examples. 

the  last  sentence  above  echoes  the  Algol  68  report 

end  processing  of  LINE  is  complete 

a stand  alone  comment 
and  its  continuation 


2.7  Pragmas 


Pragmas  are  used  to  convey  information  to  the  compiler.  A pragma  begins  with  the  reserved  word 
pragma  followed  by  the  name  of  the  pragma.  A pragma  can  have  arguments,  which  csn  be  iden- 
tifiers. strings,  or  numbers. 

pragma 

pragma  identifier  ({argument  {.  argumentlll; 

argument  identifier  | character,  string  | number 

Pragmas  may  appear  before  a program  unit,  and  wherever  a declaration  or  a statement  may 
appear.  The  extent  of  the  effect  of  a pragma  depends  on  the  pragma. 

A pragma  may  be  language  defined  or  implementation  defined.  All  language  defined  pragmas  are 
described  in  Appendix  B 

Examples  of  pragmas: 

pragma  LIST(OFF);  — suppress  listing 

pragma  GPTIMIZE(TIME):  — optimiration  specification 

pragma  INClUOErCOMMON„TEXT-);  - include  text  file 

pragma  DEBUG(ON);  — set  debugging  m*jde  on 


2.8  Reserved  Word* 


The  identifiers  listed  below  ere  called  reserved  words  and  are  reserved  for  special  significance  in 
the  language.  As  such,  these  identifiers  may  not  be  declared  by  the  programmer.  For  readability  of 
this  manual,  the  reserved  words  appear  in  lower  case  boldface. 


abort 

doctors 

generic 

of 

select 

accept 

delay 

goto 

or 

separate 

accass 

delta 

others 

subtype 

aN 

digits 

out 

and 

do 

H 

array 

in 

package 

task 

assart 

initiate 

packing 

then 

at 

is 

pragma 

type 

else 

private 

slsif 

procedure 

and 

loon 

use 

begin 

entry 

raise 

body 

exception 

mod 

range 

exit 

record 

when 

s 

E 

• 

i 

while 

new 

restricted 

case 

for 

not 

return 

constant 

function 

null 

reverse 

xor 

3.  Declaration*  and  Type* 


This  chapter  describes  the  types  in  the  language  and  the  rules  for  declaring  constants  and 
variables. 


3.1  Declaration* 


A declaration  associates  an  identifier  with  a declared  entity.  Each  identifier  must  be  declared 
before  it  is  used,  with  the  exception  of  labels.  There  are  several  kinds  of  declarations. 


declaration  ::= 

object  .declaration 
| subtype_declaration 
I subprogram_declaration 
| entry_declaration 
| renaming_declaration 


I type_declaration 
j private_type_declaration 
| module_declaration 
| exception  declaration 


The  process  by  which  a declaration  achieves  its  effect  is  called  the  elaboration  of  the  declaration. 
Any  expression  appearing  in  a declaration  is  evaluated  when  the  declaration  is  elaborated  unless 
otherwise  stated. 


Object,  type,  and  subtype  declarations  are  described  here  The  remaining  declarations  are 
described  in  later  chapters. 


3.2  Object  Declaration* 


An  object  is  a variable  or  a constant.  An  object  declaration  introduces  one  or  more  named  objects 
of  a given  type.  These  objects  can  only  have  values  of  this  type. 

object-declaration  ::= 

identifier Jist  : | constant | type  (:=  expression!; 
identifierJist  :;=  identifier  |,  identifier) 

An  object  declaration  may  include  an  expression  which  specifies  the  initial  value  of  the  declared 
objects.  This  expression  is  evaluated  and  its  value  is  assigned  to  each  of  the  declared  objects,  as 
part  of  the  elaboration  of  the  object  declaration. 

An  object  is  a constant  if  its  declaration  includes  the  reserved  word  constant.  The  value  of  a cons 
tant  cannot  be  modified.  If  a constant  object  has  components,  they  cannot  be  modified. 
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It  is  possible  to  defer  the  initialization  of  a constant  record  component  (see  3.7 .1)  and  of  a cons 
tent  of  a private  type  declared  in  the  visible  part  of  a module  (see  7.4) 

Examples  of  variable  declarations. 


ITEM_1 . ITEM- 2 

SORT_COMPLETED 

OPTION-TABLE 


: INTEGER, 

BOOLEAN  : FALSE; 
array  (1  . N)  of  OPTION; 


Examples  of  constant  declarations. 


LIMIT 

LOW_LIMIT 

TOLERANCE 

LENGTH 


constant  INTEGER 
constant  INTEGER 
constant  FLOAT 
constant  INTEGER. 


■=  1 CLOOO; 

= LIMIT/10; 

= SQRT(X); 

--  deferred  initialization; 


Notes: 


The  expression  initializing  a constant  may  (but  need  not)  be  a static  expression  (see  4.8).  In  the 
above  examples.  LIMIT  and  LOW-LIMIT  are  initialized  with  static  expressions,  but  TOLERANCE  is 
not. 


3.3  Typa  and  Subtypa  Declarations 


A type  characterizes  a set  of  values  and  a set  of  operations  applicable  to  those  values.  The  values 
are  denoted  by  literals  or  aggregates  of  the  type,  or  can  be  obtained  as  the  results  of  operations. 
The  operations  and  the  properties  of  the  values  are  said  to  be  attributes  of  the  type.  Any  sub- 
program with  a parameter  or  result  of  the  type  is  an  attribute  of  the  type. 

There  exist  several  classes  of  types.  Scalar  types  are  types  whose  values  have  no  components; 
they  comprise  types  defined  by  enumeration  of  their  values,  integer  types,  and  real  types  Array 
and  record  types  are  composite,  their  values  consist  of  several  component  values.  An  access  type 
is  a type  whose  values  provide  access  to  other  objects.  The  attributes  resulting  from  the  definition 
of  these  classes  of  types  are  predefined  attributes  (see  4.1.3).  Finally,  there  are  private  types 
where  the  set  of  possible  values  is  clearly  defined,  but  not  known  to  the  users  of  such  types. 
Hence,  a private  type  is  only  known  by  the  set  of  operations  applicable  to  its  values  (see  7.4). 

The  set  of  possible  values  of  a type  can  be  restricted  without  changing  the  set  of  applicable  opera 
tions.  Such  a restriction  is  called  a constraint.  A value  is  said  to  belong  to  a subtype  of  a given  type 
if  it  obeys  such  a constraint.  Naturally,  subtypes  may  not  be  found  for  user  defined  private  types 
since  nothing  is  known  a priori  about  the  set  of  possible  values. 

type  ::=  type_definition  | type_mark  Iconstraint) 

type_definition 

enumeration_type -definition  | integer- type_ definition 

I real_type_definition  | array_type_definition 

I record_type_definition  j access_type_definition 

| derived_type_definition 


type_jmark  ::  fypa_name  | subtype-name 


constraint  ::= 

range_constraint  | accuracy_constraint 
I index_constraint  | discriminant_constraint 


type  ..declaration  ::= 

type  identifier  (is  type  definition |; 

subtype_declaration  :: 

subtype  identifier  is  type_mark  |constraint|; 


Every  type  definition  introduces  a distinct  type.  A type  declaration  associates  a name  with  a type 
A subtype  declaration  introduces  a name  as  an  abbreviation  for  a type  name  with  some  possible 
constraint.  Each  constraint  is  evaluated  when  the  declaration  in  which  it  appears  is  elaborated. 


An  incomplete  type  declaration  of  the  form 


type  T: 

is  used  for  the  declaration  of  mutually  dependent  access  types  (see  3.8);  the  complete  type 
declaration  must  follow  in  the  same  declarative  part. 

Examples  of  type  declarations ; 

type  COLOR  is  (WHITE,  RED,  YELLOW.  GREEN,  BLUE,  BROWN,  BLACK); 

type  COI_NUM  is  range  1 ..  72; 

type  TABLE  is  array  (1  ..  10)  of  INTEGER; 

Examples  of  subtype  declarations'. 

subtype  RAINBOW  is  COLOR  range  RED  BLUE; 
subtype  SMALLINT  is  INTEGER  range  -10  . 10; 
subtype  ZONE  is  COLNUM  range  1 . 6; 

Notes'. 

Two  type  definitions  always  introduce  two  distinct  types,  even  if  they  are  textually  identical.  For 
example,  the  enumeration  type  definitions  given  in  the  declarations  of  A and  B below  define  dis- 
tinct types,  although  the  set  of  values  of  one  of  them  is  a copy  of  the  set  of  values  of  the  other. 

A : (ON,  OFF); 

B : (ON.  OFF); 

On  the  other  hand,  C and  D in  the  following  declaration  are  of  the  same  type,  since  only  one  type 
definition  is  given. 

C,  D : (WHITE.  GREY,  BLACK); 
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3.4  Derived  Type  Definitions 


A derived  type  definition  introduces  a new  type  deriving  its  characteristics  from  those  of  an 
existing  type 

derived_typeJdefinition  ::=  new  type_mark  |constraint| 

With  a type  declaration  of  the  form: 
type  NEW_TYPE  is  new  01D_TYPE. 

the  new  type  derives  all  its  characteristics  from  those  of  the  old  type: 

• The  new  type  belongs  to  the  same  class  of  types  as  the  old  type  (for  example,  the  new  type  is 
a record  type  if  the  old  type  is)  and  the  same  attributes  are  predefined. 

e The  set  of  values  of  the  new  type  is  a copy  of  the  set  of  values  of  the  old  type.  The  constraints 
associated  with  the  old  type  apply  to  objects  of  the  new  type. 

• Tne  notation  for  literals  or  aggregates  of  the  new  type  is  the  same  as  for  the  old.  Such  literals 
and  aggregates  are  said  to  be  overloaded.  The  notation  used  to  denote  components  of  objects 
of  the  new  type  is  the  same  as  for  the  old. 

• For  each  visible  subprogram  attribute  of  tne  old  type,  a subprogram  attribute  of  the  new  type 
is  derived  in  which  occurrences  of  the  name  of  the  old  type  are  in  effect  replaced  by  the  name 
of  the  new  type.  Such  subprograms  are  said  to  be  overloaded.  Assignment  is  available  for  the 
new  type  if  it  is  for  the  old. 

• Any  explicit  representation  specification  (see  1 3)  given  for  the  old  type  also  applies  to  the  new 
type. 

The  effect  of  such  a type  declaration  is  thus  to  create  a new  type  distinct  from  the  old  type,  but 
equivalent  in  effect  to  what  would  be  obtained  by  duplicating  the  old  type  definition  and  all  its 
applicable  operations.  Explicit  conversions  are  allowed  between  the  old  type  and  the  new  type  (see 
4.6.2). 

A type  declaration  of  the  form: 

type  NEW_TYPE  ia  new  OLD_TYPE  constraint. 

is  equivalent  to  the  succession  of  declarations: 

type  new  type  is  new  OLD_TYPE; 
subtype  NEW_TYPE  is  new  type  constraint. 

where  new  type  is  an  identifier  distinct  from  those  of  the  program.  Hence,  the  values  and  opera- 
tions of  the  old  type  are  inherited  by  the  new  type,  but  objects  of  the  new  type  must  satisfy  the 
added  constraint. 
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3.5  Scalar  Typas 


Scalar  types  comprise  discrete  types  and  real  types.  Discrete  types  are  the  enumeration  types  and 
integer  types;  they  may  be  used  for  indexing  and  iteration  over  loops.  Numeric  types  are  the 
integer  and  real  types.  All  scalar  types  are  ordered.  A range  constraint  specifies  a subset  of  values 
of  the  type  or  subtype. 

range_constraint  rang*  range 

range  simple_expression  simple_expression 

The  range  L R describes  the  values  from  L to  R inclusive.  An  empty  range  is  a range  for  which  L is 
greater  than  R.  The  type  of  the  simple  expressions  in  a range  constraint  is  the  type  for  which  the 
range  constraint  is  specified 

Predefined  Attributes 

For  any  scalar  type  or  subtype  T.  the  following  attributes  are  predefined  (see  also  4. 1 .3  and  Appen- 
dix A): 

T FIRST  the  minimum  value  of  the  type  or  subtype  T 

T'LAST  the  maximum  value  of  the  type  or  subtype  T 

For  every  discrete  type  or  subtype  T,  the  subprogram  attributes  T'SUCC,  T'PRED.  and  T'ORD  are 
predefined  as  follows: 

TSUCC(X)  the  value  succeeding  the  value  X in  T 

T'PRED(X)  the  value  preceding  the  value  X in  T 

T’ORD(X)  the  ordinal  position  of  the  value  X in  T.  For  example  T'ORD(T'FIRST)  = 1 

The  exception  RANGE_ERROR  is  raised  by  the  function  call  T SUCC(T  LAST)  and  similarly  by 
T' PR  EDIT' FIRST). 


3.5.1  Enumeration  Types 


An  enumeration  type  definition  introduces  a set  of  values  by  listing  the  values. 

enumeration_type_definition  .:= 

(enumerationJiteral  |,  enumerationjiterall) 

enumerationjiteral  ::  identifier  | characterjiteral 

An  enumerated  value  is  represented  by  an  identifier  or  a character  literal.  Hence,  a character  set 
can  be  defined  by  an  enumeration  type.  Order  relations  between  enumeration  vaues  follow  the 
order  of  listing,  the  first  being  less  than  the  last. 

Within  a sequence  of  declarations,  an  enumeration  literal  can  appear  in  different  enumeration 
types.  Such  enumeration  literals  are  said  to  be  overloaded.  When  ambiguities  arise  in  the  use  of 
such  literals  they  can  be  resolved  by  providing  an  explicit  qualification  (see  4.6). 
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Examples 


type  DAY 
type  SUIT 
type  HEXA 
type  COLOR 
typ*  LIGHT 


to  (MON  TUE.  WED.  THU.  FRI.  SAT.  SUN) 
to  (CLUBS  DIAMONDS  HEARTS.  SPADESI 

to  C A".  -B*  "C  *D*.  •£',  ‘F”). 

to  (WHITE  RED  YELLOW.  GREEN.  BLUE  BROWN  BLACK), 
to  (RED,  AMBER.  GREEN);  — RED  and  GREEN  are  overloaded 


autotype  WEEK_DAV  to  DAY 
autotype  MAJOR  to  SUIT 
autotype  RAINBOW  to  COLOR 


MON  FRI 
HEARTS  SPADES 

RED  BLUE:  — the  color  RED  not  the  light 


3-5.2  Character  Types 


A character  type  is  an  enumeration  type  that  contains  character  literals  and  possibly  identifiers 

The  predefined  type  CHARACTER  denotes  the  full  ASCII  character  set  of  128  characters  (see 
Appendix  C) 


3.5.3  Boolean  Type 


There  is  a predefined  enumeration  type  named  BOOLEAN  It  contains  the  two  literals  FALSE  end 
TRUE  ordered  with  the  relation  FALSE  < TRUE  The  evaluation  of  conditions  delivers  results  of  this 


3.5.4  Integer  Types 


The  predefined  type  named  INTEGER  denotes  a subset  of  the  integers.  Other  integer  types  can  be 
introduced  by  integer  type  definitions  or  can  be  derived  from  the  type  INTEGER 

integer_type_.definttion  range  .constraint 

The  range  of  integer  numbers  is  implicitly  limited  by  the  representation  adopted  by  an  individual 

!'riwrrnmict^c o An  ,mP,emenlation  rn*V  h"ve  predefined  types  such  as  SHORTJNTEGER  and 
LONG_INTEGER  which  have  respectively  shorter  and  longer  ranges  than  INTEGER. 

A type  declaration  of  the  form 

typa  T it  rang*  L R: 

where  L and  R denote  integer  values  introduces  an  integer  type  equivalent  to 
typ*  T to  n*w  integer  type  rang*  L . R. 

where  the  integer  type  is  implicitly  chosen  so  as  to  contain  the  values  L through  R and  is  one  of 
the  predefined  types  such  as  SHORTJNTEGER  INTEGER,  or  LONGJNTEGER. 


Examples: 


type  PAGE.NUM  la  rang*  1 ..  2_000. 
type  LINE-SIZE  is  new  INTEGER  rang*  1 ..  MAX-LINE-SIZE ; 

•ubtypa  SMALL.INT  la  INTEGER  ranga  -10  ..  10; 

subtype  COLUMN-PTR  la  LINE-SIZE  range  1 ..  10; 

Notes: 

II 

The  smallest  integer  value  supported  by  the  implementation  is  SYSTEM'MINJNT  and  the  largest 
value  SYSTEM'MAXJNT. 


3.5.5  Real  Types 


Real  types  provide  approximations  to  the  real  numbers,  with  relative  bounds  on  errors  for  floating 
point  types,  and  with  absolute  bounds  on  errors  for  fixed  point  types. 

real_lype_definition  ::=  accuracy-constraint 

accuracy-constraint 

digita  simple_expression  |range_constraint| 

| delta  simple_expression  |range_constraintj 

For  floating  point  types  the  error  bound  is  specified  as  a relative  precision  by  giving  the  minimum 
number  of  decimal  digits  for  the  mantissa. 

A given  implementation  can  have  predefined  floating  point  types,  such  as  SH0RT_FL0AT,  FLOAT, 
and  L0NG_FL0AT.  which  correspond  to  the  hardware  supplied  floating  point  types.  Reei  type 
definitions  of  the  forms 

digits  P 

digita  P ranga  L ..  R 

where  P is  a static  integer  expression  (see  4.8)  specifying  a number  of  decimal  digits,  and  where  L 
and  R are  floating  point  values,  are  equivalent  to  the  type  definitions 

new  floating  point  type  digits  P 

new  floating  point  type  digits  P ranga  L . R 

where  floating  point...type  is  implicitly  chosen  as  an  appropriate  predefined  floating  point  type. 
The  implemented  precision  must  be  at  least  that  of  the  precision  specified  in  the  corresponding 
definition.  If  a range  is  provided,  it  must  be  covered  by  the  chosen  predefined  type. 

For  fixed  point  types,  the  error  bound  is  specified  as  an  absolute  value,  called  the  delta  of  the  fixed 
point  type.  The  implemented  error  bound  must  be  at  least  as  fine  as  the  specified  delta.  In  a fixed 
point  type  definition,  the  range  constraint  cannot  be  omitted,  since  this  determines  the  representa- 
tion to  be  used  for  values  of  the  type;  the  expressions  specifying  the  range  and  the  delta  must  be 
static  expressions. 
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In  a subtype  or  object  declaration,  an  accuracy  constraint  can  be  applied  to  a previously  declai 
real  type  For  a fixed  point  type,  the  delta  of  the  constraint  cannot  be  smaller  than  the  delta  of  th 
type  For  a floating  point  type,  the  number  of  digits  specified  in  the  constraint  cannot  be  larger  than 
that  of  the  type.  In  all  cases,  the  delta  or  the  digits  must  be  given  by  static  expressions. 

Examples 

type  COEFFICIENT  is  digits  10  range  -10  10 

type  VOLT  is  delta  0 125  range  0 0 255  0; 

type  FRAC  m delta  0 00001  range  0 0 1.0; 

type  MASS  is  new  FLOAT  digits  7 range  0 0 1E30. 

subtype  S_V0LT  is  VOLT  delta  0 5:  - same  range  as  VOLT 

subtype  COEFF  is  COEFFICIENT  digits  8. 

Predefined  A t tributes 

For  a floating  point  type  or  subtype  T,  the  following  attributes  are  predefined: 

T DIGITS  the  specified  number  of  digits  (it  is  of  type  INTEGER) 

T SMALL  the  smallest  positive  value  expressible  with  the  representation  and  precision  of 

type  T 

T LARGE  the  largest  positive  value  expressible  with  the  representation  and  precision  of  type 

For  a fixed  point  type  or  subtype  T.  the  following  attribute  is  predefined: 

T DELTA  the  value  of  the  specified  delta 

For  any  real  type  T the  following  attribute  is  predefined: 

T BITS  the  minimum  number  of  bits  needed  for  the  representation  of  the  mantissa  of  T 


3.6  Array  Types 

An  array  object  is  a set  of  components  of  the  same  component  type.  A component  of  an  array  is 
designated  using  one  or  more  index  values  belonging  to  specified  discrete  types 

array_type_definition  ::= 

array  (index  |,  indexl)  of  type_mark  Iconstraint) 
index  ::=  discrete_range  | tyi>e_mark 
discrete_range  ::=  |type_mark  range  I range 
index_constreint  :;=  (discrete_rat\ge  |.  discrete_range|) 
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An  array  object  is  characterized  by  the  number  of  indices,  the  type  of  each  index,  the  lower  and 
upper  bound  for  each  index,  and  the  type  and  possible  constraints  of  the  components.  In  an  array 
type  definition,  each  index  can  be  specified  either  by  a discrete  range  or  by  a type  mark.  These  two 
forms  of  index  specifications  have  different  consequences: 


( 1 ) Index  specified  by  a discrete  range 

For  all  objects  of  the  array  type,  the  discrete  range  determines  both  the  permitted  type  for  the 
index  values  and  the  lower  and  upper  bound  for  the  index  values 


(2) 


Index  specified  by  a type  mark 

For  all  objects  of  the  array  type,  the  type  mark  only  determines  the  permitted  type  for  the 
index  values.  The  actual  values  of  the  lower  and  upper  bound  of  the  index  considered  can  be 
different  for  different  objects  of  the  array  type 

The  bounds  must  be  given  for  each  array  separately  in  its  object  declaration  by  an  index  con- 
straint. or  can  be  obtained  from  the  initial  value.  For  an  array  formal  parameter,  the  bounds 
are  obtained  from  the  actual  parameter. 


For  a multi-dimensional  array  if  one  index  position  is  specified  by  a discrete  range,  all  index  posi- 
tions must  be  specified  by  discrete  ranges  Similarly,  an  index  constraint  must  provide  ranges  for 
all  index  positions  For  accessing  components,  an  n-dimensional  array  is  equivalent  to  a one- 
dimensional array  of  (n- 1 (-dimensional  subarrays. 


If  the  bounds  of  a discrete  range  are  integer  numbers,  these  are  assumed  to  be  of  the  predefined 
type  INTEGER  if  their  type  is  not  otherwise  known  from  the  context. 


Predefined  Attributes 


For  an  array  object  A (or  for  an  array  type  A with  specified  bounds),  the  following  attributes  are 
predefined  (/'  is  an  integer  value): 


A FIRST 
A LAST 
A LENGTH 


the  lower  bound  of  the  first  index 
the  upper  bound  of  the  first  index 
the  number  of  components  of  the  first  index 
(zero  when  no  components) 


A'FIRST(z)  the  lower  bound  of  the  /- th  index 

A LAST)/)  the  upper  bound  of  the  /-th  index 

A' LENGTH!/)  the  number  of  components  of  the  /-th  index 


Examples  of  array  types  with  specified  bounds. 


type  TABLE  it  array  (1  ..  10)  of  INTEGER; 

type  SCHEDULE  is  array  (DAYFIRST  ..  DAY  LAST)  of  BOOLEAN: 

typo  LINE  is  array  (1  ..  MAX_LINE_SIZE)  of  CHARACTER. 

Examples  of  array  types  with  unspecified  bounds: 

typo  MATRIX  is  array  (INTEGER.  INTEGER)  of  REAL; 

typo  BIT_VECTOR  is  array  (INTEGER)  of  BOOLEAN; 


Examples  of  array  declarations : 


GRID  : array  (1  ..  80,  1 ..  100)  of  BOOLEAN; 

MIX  : array  (COLOR  range  RED  GREEN)  of  BOOLEAN. 

MY_TABLE  TABLE;  — all  arrays  of  type  TABLE  have  the  same  length 
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BOARD  ; MATRIX  (1  ..  8.  1 ..  8). 

RECTANGLE  MATRIX  (1  20  1 ..  30): 

~ MY_TA8LE  FIRST  = 1.  BOARDLAST(I)  = 8 RECTANGLE'LAST(2)  = 30 


3.6.1  Index  Ranges  of  Arrays 


The  range  of  each  index  of  an  array  must  be  known  when  the  declaration  of  the  array  is  elaborated 
(or  when  allocated  in  the  case  of  access  types).  The  expressions  defining  the  range  of  an  index 
need  not  be  static,  but  can  depend  on  computed  results.  Such  arrays  * * called  dynamic  arrays.  In 
records,  dynamic  arrays  may  only  appear  when  the  dynamic  bounoo  are  discriminants  of  the 
record  type 

Examples: 

SQUARE  : MATRIX  (1  ..  N.  1 ..  N);  — N need  not  be  static 

type  VAR_LINE  is  accsss 
record 

LENGTH  constant  INTEGER:  — value  given  on  initialization 

IMAGE  : STRING!  1 ..  LENGTH); 

end  record; 


3.6.2  Aggregates 


An  aggregate  denotes  an  array  or  record  value  constructed  from  component  values, 
aggregate 

(component_association  |,  component_association|) 

component_association 

Ichoice  j|  choice!  - > | expression 

choice  "=:  simple_expression  | discrete_range  | others 

The  expressions  define  the  values  to  be  associated  with  components  They  can  be  given  by  posi- 
tion (in  index  order  for  array  components,  in  textual  order  for  record  components)  or  by  naming  the 
chosen  components  (with  index  values  for  array  components,  with  the  corresponding  identifiers  fot 
record  components).  An  aggregate  defining  the  value  of  an  object  must  provide  values  for  all  com- 
ponents of  the  object. 

For  named  components,  the  expressions  can  be  given  in  any  order,  but  if  both  notations  are  used 
in  one  aggregate,  the  positional  component  associations  must  be  given  first. 

A choice  g as  a discrete  range  stands  for  all  index  values  in  the  range  The  choice  others  stands 
for  all  components  not  specified  by  previous  choices  and  can  only  appear  last.  Choices  with  dis- 
crete values  are  also  used  in  variant  parts  of  records  and  in  case  statements.  Each  choice  may  only 
appear  once  in  an  aggregate  (variant  part  or  case  statement)  and  except  for  the  choice  others  its 
value  must  be  determinable  statically. 
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When  an  aggregate  used  as  an  initial  value  is  expected  to  provide  tl  uounds  of  an  array  object, 
the  choice  others  cannot  be  used  For  an  array  whose  index  is  only  specified  by  a type  mark  T,  the 
lower  bound  is  assumed  to  be  equal  to  T FIRST  it  the  initialization  is  given  by  a positional 
aggregate. 

An  aggregate  tor  an  n-dimensional  array  is  written  as  a one-dimensional  aggregate  ot  components 
that  are  (n-1  (-dimensional  array  values 

Examples: 

A TABLE  :=  (7,9,5. 1 ,3, 2, 4, 8. 6,0);  - A(1)  - 7,  A00)  = 0 

B : TABLE  :=  (5,4, 8,1,  others  =>  20);  B (1)  5,  BOO)  = 20 

C : TABLE  :=  (2  | 4 | 10  =>  1.  others  > 01;  ••  Cdl  0,  CI10I  1 

NULL. MATRIX  : constant  MATRIX  :=  (1  10  =>  (1  10  > 0.0)1; 

--  NULL-MATRIX  FIRST!  1)  = 1,  NULL-MATRIX  LASTI2)  10 

ENGLISH-SCHOOL.DAYS  : constant  SCHEDULE  : (MUN  ..  FRl  > TRUE.  others  =>  FALSE); 
FRENCH  .SCHOOLDAYS  : constant  SCHEDULE  : (WED  | SUN  > FALSE,  others  > TRUE): 


3.6.3  Strings 


The  predefined  type  STRING  denotes  one-dimensional  arrays  ot  the  predefined  type  CHARACTER, 
indexed  by  values  of  the  predefined  subtype  NATURAL; 

subtype  NATURAL  is  INTEGER  range  1 ..  INTEGER  LAST; 
type  STRING  is  array  (NATURAL)  of  CHARACTER. 

Character  strings  (see  2.5)  are  a special  form  ot  aggregate  applicable  to  the  type  STRING  and 
other  one-dimensional  arrays  of  characters. 

Catenation  is  a predefined  operator  over  one-dimensional  arrays,  and  is  represented  as  &.  For  str 
ings,  it  corresponds  to  the  following  function: 

function  "8T  (X.  Y : STRING)  return  STRING  is 
S : STRING)  1 . X LENGTH  +■  Y LENGTH); 

begin 

Sd  ..  XLENGTH)  : X; 

SIX  LENGTH  + 1 . S LAST)  :=  Y; 

return  S; 
end; 

Examples : 

BLANKS  : STRlNGd  ..  120)  :=  d ..  120  =>  " "); 

MESSAGE  : constant  STRING  "HOW  MANY  CHARACTERS 7"; 

MESSAGEFIRST  1,  MESSAGE'LAST  number  of  characters 

SAY-TWICE  ; constant  STRING  MESSAGE  & MESSAGE  8.  CR  8.  LF; 
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3.7  Record  Types 


A record  ob)ect  is  a structure  with  named  components.  A record  type  definition  can  include  a 
variant  part  denoting  alternative  record  structures. 

record Jvpe  definition  ::= 

record 

componentjist 

end  record 


componentjist 

lobject_declaration|  ivanant  .part)  | null; 

variant, .part 

caee  discriminant  of 

(when  choice  ||  choice | 
componentjist  | 

end  case. 


discriminant  constant  componenf_name 

The  components  of  a record  are  defined  by  object  declarations.  Components  can  be  of  different 
types.  The  value  of  an  expression  provided  as  a component  initialization  is  evaluated  when  the 
record  type  definition  is  elaborated.  This  value  is  used  to  initialize  the  corresponding  component 
for  every  record  declared  of  this  type. 


Recursion  in  record  type  definitions  is  not  allowed  unless  an  intermediate 
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access  type  is  used  {see 


Examples: 

type  DATE  is 
record 

DAY  INTEGER  range  1 31; 

MONTH  : MONTH...NAME; 

YEAR  ; INTEGER  range  0 . 2000. 

end  record. 

type  COMPLEX  is 


RE  : FLOAT  : = 0 0 
IM  ; FLOAT  :=  00: 

end  record. 


both  components  of  every  complex 


record  are  initialized  to  zero 


3.7.1  Constant  Record  Components  and  Discriminants 


A constant  component  of  a record  which  is  not  given  an  explicit  value  in  the  type  definition  is  a 
deferred  constant  Such  a deferred  constant  can  only  be  assigned  by  means  of  a complete  record 
assignment. 
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A record  component  can  be  a dynamic  array  only  if  the  bounds  that  are  not  static  are  deferred  con- 
stant components  of  the  record  type.  A deferred  constant  component  used  in  this  way  or  in  a 
variant  part  is  called  a discriminant  of  the  record  type. 


: 


l 

The  only  permissible  dependencies  between  record  components  are  the  dependencies  of  an  array 
bound  and  of  a variant  on  a discriminant. 

Example. 

type  BUFFER  is 
record 

LENGTH  : constant  INTEGER  range  1 ..  MAX_LENGTH:  — the  discriminant 
POS  : INTEGER  range  0 ..  MAX_LENGTH  :=  0; 

IMAGE  : array  (1  ..  LENGTH)  of  CHARACTER; 

end  record: 


3.7.2  Variant  Parts 


A record  type  with  a variant  part  specifies  alternative  record  components.  Each  variant  defines  the 
components  for  the  corresponding  value  of  the  discriminant.  A variant  can  have  an  empty  compo- 
nent list,  which  must  be  specified  by  null. 

Example'. 

type  PERIPHERAL  is 
record 

STATUS  : (OPEN,  CLOSED); 

UNIT  : constant  (PRINTER,  DISK,  DRUM);  — the  discriminant 
case  UNIT  of 

when  PRINTER  => 

LINE_COUNT  ; INTEGER  range  1 ..  PAGE.SIZE; 

when  others  = > 

CYLINDER  ; CYLINDER JNDEX; 

TRACK  : TRACK_NUMBER; 

end  case; 
end  record; 


3.7.3  Record  Aggregates  and  Discriminant  Constraints 

An  aggregate  is  used  to  provide  values  for  all  the  components  of  a record.  In  an  aggregate  for  a 
record  variant,  the  discriminant  value  must  be  a static  expression  and  must  appear  before  the 
values  for  the  corresponding  components  of  the  variant  part. 

discriminant_constraint  ::=  aggregate 

A discriminant  constraint  is  used  to  constrain  discriminants  of  a record  to  specific  values:  it  is 
expressed  as  an  aggregate  specifying  values  for  discriminants  only.  Discriminant  constraints  may 
be  used  to  define  subtypes  of  record  types  with  variants. 
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Examples  of  record  aggregates: 


(4  JULY.  1776) 

(DAY  =>'4,  MONTH  > JULY.  YEAR  -->  1776) 
(STATUS  CLOSED.  UNIT  > DISK,  CYLINDER 


= > 9.  TRACK  =>  1) 


Examples  of  record  variable  declarations  with  constraints 
WRITER  PERIPHERAL!  PR  INTER): 

[ CARD  BUFFERILENGTH  =>  80); 


Example  of  record  subtype 

»ubtyp«  DISK_DEVICE  ia  PERIPHERAUUNIT  ->  DISK): 


3.8  Accesa  Typaa 


Objects  declared  in  a program  are  accessible  by  their  name.  They  exist  during  the  lifetime  of  the 
declarative  part  to  which  they  dre  local.  In  contrast,  objects  may  also  be  created  dynamically  by 
the  execution  of  allocators  (see  4.7).  Since  they  do  not  occur  in  an  explicit  object  declaration,  they 
cannot  be  designated  by  their  name.  Instead,  access  to  such  an  object  is  achieved  by  an  access 
value  returned  by  an  allocator. 

access  type  .definition  access  type 

An  access  type  definition  characterizes  a set  of  access  values  which  may  be  used  to  designate 
objects  of  the  type  mentioned  after  the  reserved  word  accesa.  This  type  cannot  be  another  access 
type  The  dynamically  created  objects  designated  by  the  values  of  an  access  type  form  a collection 
implicitly  associated  with  the  type  An  access  value  obtained  from  an  allocator  can  be  assigned  to 
several  access  variables.  Hence  a given  dynamically  created  object  may  be  designated  by  more 
than  one  variable  or  constant  of  the  access  type.  The  access  value  null  belongs  to  every  access 
type  and  designates  no  object  at  all  It  may  be  used  to  initialize  access  variables. 

An  object  of  an  access  type  that  is  introduced  as  a constant  c annot  have  its  value  changed,  nor  can 
the  value  of  the  designated  object  be  changed.  Such  an  access  object  can  only  be  used  in  an 
expression  or  as  an  in  parameter:  it  cannot  be  assigned  to  an  access  variable  (otherwise  the 
designated  object  could  be  modified  using  the  variable). 

Constraints  specified  for  an  access  type  apply  to  the  type  of  the  designated  objects  Qualification 
of  an  expression  of  an  access  type  applies  to  the  designated  object 

Although  the  dynamically  created  objects  may  not  be  of  an  access  type,  there  is  no  restriction  on 
their  components  Thus,  components  of  the  object  designated  by  the  values  of  an  access  type  may 
be  values  of  the  same  or  of  another  access  type.  This  permits  recursive  and  mutually  dependent 
access  types  (whose  declaration  requires  a prior  incomplete  type  declaration  for  one  or  more 
types). 
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Examples: 

type  TEXT  is  accsss  BUFFER; 

typs  LIST_ITEM  is  accsss 
record 

VALUE  ; INTEGER; 

SUCC  : LISTJTEM; 

PRED  : LISTJTEM; 

and  record; 

HEAD  : LISTJTEM  :=  null: 

Example  of  mutually  dependent  access  types : 


type  CAR; 


a prior  incomplete  type  declaration 


type  PERSON 
record 
NAME 
AGE 

SPOUSE 

VEHICLE 

end  record; 


is  access 

: STRING)  1 ..  20); 

: INTEGER  range  0 130; 

PERSON; 

: CAR;  — valid  because  CAR  declared  above 


type  CAR  is  access  - the  complete  type  declaration 

,"CNUMBER  : INTEGER; 

OWNER  : PERSON; 
end  record: 

MY_CAR,  Y0UR_CAR.  NEXT_CAR  : CAR; 
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4.  Names,  Variables,  and  Expresaiona 


4.1  Names 


Na^es  denote  declared  entities  such  as  variables,  constants,  types,  and  program  units. 


name  ::= 

identifier  | indexed_component 

| selected_component  | predefined_attribute 


indexed_component 

selected_componant 

predefined_attribute 


:=  name(expression  |.  expression)) 


= name  . identifier 


= name  ' identifier 


The  simplest  form  for  the  name  of  an  entity  is  the  identifier  given  in  its  declaration. 

Examples  of  simple  names: 

INDEX  — the  name  of  a scalar  variable 

GRID  — the  name  of  an  array  variable 

FLOAT  — the  name  of  a type 

SORT  --  the  name  of  a function 

OVERFLOW  --  the  name  of  an  exception 


4.1.1  Indexed  Components 


An  indexed  component  can  denote  either 

(a)  A component  of  an  array: 

The  name  identifies  the  array,  (or  an  access  object  whose  value  designates  the  array,  see  3.8) 
and  the  expressions  give  the  indices  for  the  component.  If  the  array  has  more  dimensions  than 
the  given  number  of  expressions,  the  array  component  is  a subarray  of  the  named  array. 

(b)  A task  in  a family  of  tasks: 

The  name  identifies  the  task  family  and  the  expression  (only  one  can  be  given'  specifies  the 
index  of  the  individual  task. 
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(c)  An  entry  in  a family  of  entries: 


The  name  identifies  the  entry  family 
index  of  the  individual  entry 


and  the  expression  (only  one  can  be  given)  specifies  the 


!,hfVa,Ha,,0.10f  006  °f  ,h<!  ®*pressions  9ives  an  index  value  that  is  outside  the  range  specified  for 

the  index,  the  exception  INDEX_ERROR  is  raised:  M 


Examples  of  indexed  components 


GRIDO.  J+1) 

GRID(2> 

PRINTER(I) 


an  array  component 
a subarray  of  GRID 
o task  in  the  task  family  PRINTER 


4. 1 .2  Selected  Components 


A selected  component  can  denote  either 


(a)  A component  of  a record: 


The  name  identifies  the  record  (or  an  access  object  whose  value 
the  identifier  specifies  the  record  component. 


designates  the  record)  and 


(b)  An  entity  declared  in  the  visible  part  of  a module: 


The  name  identifies  the  module  and  the  identifier  specifies  the  declared  entity, 
(c)  An  entity  declared  in  an  enclosing  unit: 


The  name  identifies  the  enclosing  unit  and  the  identifier  specifies  the  declared  entity, 
(d)  A user-defined  attribute  of  a type:  N'- 


,VPe  and  the  iden,if'er  specifies  a user  defined  subprogram  attribute 


For  variant  records,  a component  identifier  can  denote  a component 
case,  the  selected  component  must  belong  to  the  variant  prescribed 
record,  otherwise  the  exception  DISCRIM!NANT_ERROR  is  raised. 


in  a variant  part.  In  such  a 
by  the  discriminant  of  the 


Examples  of  selected  components: 


APPOINTMENT.  DAY 
NEXT.SUCC.  VALUE 
KEY_TABLE(SYM80l.)  LENGTH 


— a record  component 
-*  a record  component 

— a record  component 


DEVICE. READ 
PRINTER(I). WRITE 
TABLE.  MANAGER. INSERT 


an  entry  of  the  task  DEVICE 
- an  entry  of  the  task  PRINTER(I) 

a procedure  in  the  package  TABLE_MANAGER 


MAIN  ITEM..COUNT 
STACK  MAX  SIZE 


a variable  declared 
an  attribute  of  the 


in  the  procedure  MAIN 
type  STACK 


Notes: 


For  a record  structure  with  nested  record  structures,  the  name  of  each  level  must  be  given  to  name 
a nested  component. 


4.1.3  Predefined  Attributes 


For  user-defined  attributes,  as  explained  above,  the  notation  of  selected  components  is  used;  the 
named  entity  is  a type,  and  the  attribute  identifier  is  a subprogram  provided  by  the  user.  For 
predefined  attributes,  the  apostrophe  notation  is  used;  the  named  entity  need  not  be  a type  and 
the  attribute  identifier  is  predefined  in  the  language.  A predefined  attribute  identifier  is  always 
prefixed  by  an  apostrophe,  hence  these  identifiers  are  not  reserved  Specific  predefined  attributes 
are  described  with  the  corresponding  language  constructs. 


Appendix  A gives  a list  of  all  the  language  predefined  attributes.  Additional  predefined  attributes 
may  exist  for  an  implementation. 

Examples  of  predefined  attributes 


COLOR'FIRST 

FLOAT'DIGITS 

GRIDLAST12) 

PRINTERID'ACTIVE 

DATESIZE 

CARD-ADDRESS 


minimum  value  of  the  enumeration  type  COLOR 
precision  of  the  real  type  FLOAT 
upper  bound  of  the  second  dimension  of  GRID 
TRUE  if  the  task  PRINTER(I)  is  active 
number  of  bits  for  records  of  type  DATE 
address  of  the  record  variable  CARD 


4.2  Literals 


A literal  denotes  an  explicit  value  of  a given  type, 
literal  ::= 

number  | enumeration_literal  | character_string  | null 

A number  or  an  enumeration  literal  denotes  a value  of  the  corresponding  scalar  type.  The  access 
value  null  designates  no  object  at  all.  Literals  for  approximate  numbers  are  rounded  to  the  preci- 
sion required  by  the  context  in  which  they  are  used. 


Examples: 


3.141  59_26536 

1_345 

CLUBS 

"A" 

"SOME  TEXT" 


an  approximate  number 
an  integer  number 
an  enumeration  literal 
a character  literal,  also  a character  string 
a character  string 


; 


J 
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4.3  Variables 


A variable  is  an  object  of  an  arbitrary  type  whose  value  can  be  changed  A variable  can  be  a scalar, 
an  array,  a record,  or  an  access  object.  Alternatively,  it  can  be  a component  of  another  object  or  a 
slice  of  an  array. 

variable  name  |(discrete..rangeH  | name  aN 

When  a name  is  followed  by  a discrete  range,  the  name  must  be  the  name  of  an  array  (or  subarray) 
or  of  an  access  object  whose  value  designates  an  array.  The  range  must  denote  a contiguous 
sequence  of  index  values  for  the  first  dimension  of  the  array  (or  subarray).  Such  a variable  is  called 
an  array  slice.  Its  type  is  that  of  the  array,  with  the  constraint  given  by  the  discrete  range.  For 
names  of  access  objects  with  the  qualifier  aN.  the  variable  denotes  the  entire  object  designated  by 
the  access  value. 

Examples. 

X — a scalar  variable 

GRID  — an  array  variable 

GRIDO.  J)  --  a component  of  the  arrav  variable  GRID 

GRIDd  10)  --a  slice  of  the  array  GRID 

GRID(2)(1  ..  10)  — a slice  of  the  subarray  GRID(2) 

TODAY  MONTH  — a record  component 

NEXT.CAR  OWNER  — a component  of  the  record  designated  by  NEXT_CAR 
NEXT.CAR  aN  — the  entire  record  value  designated  by  NEXT.CAR 


4.4  Expressions 


An  expression  is  a formula  that  defines  the  computation  of  a value 

expression  ::= 

relation  land  relationl 
| relation  |or  relation) 

| relation  |xor  relation) 

relation 

simple_expression  (relational .operator  simple_expressionj 
| simple  .expression  |not|  in  range 
| simple.expression  (not!  in  type.mark  (constraint! 

simple.expression  ::=  lunary.operatorl  term  |adding_operator  term| 

term  ::=  factor  | multiply ing_operator  factorl 

factor  primary  |*«  primaryl 

primary  ::= 

literal  | aggregate  | variable  | allocator 
| subprogram_call  | qualified.expression  | (expression) 
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Primaries  include  constants  and  predefined  attributes,  which  are  covered  by  the  syntactic  category 
'variable'.  An  expression  of  a given  type  is  also  regarded  as  a one-component  aggregate  for  a cor- 
responding array  or  record  type.  The  type  of  an  expression  depends  on  the  type  of  its  constituents, 
as  described  below. 

Examples  of  primaries: 

4.0 

(1  ..  10  =>  0) 

VOLUME 
DATEStZE 
SINE(X) 

REAL(I.J) 

(LINE_COUNT  + 10) 

Examples  of  expressions: 

VOLUME  — primary 

B**2  — factor 

LINE.COUNT  mod  PAGE_SIZE  - term 

-4.0  — simple  expression 

not  DESTROYED  --  simple  expression 

B**2  - 4.0*A*C  — simple  expression 

PASSWORD!  1 ..  5)  = 'JAMES'  - relation 

I not  in  1 ..  10  --  relation 

INDEX  = 0 or  ITEM_HIT  — expression 

(COLD  and  SUNNY)  or  WARM  - expression 


4.5  Operators  and  Expression  Evaluation 


The  operators  in  the  language  are  grouped  into  six  classes,  given  in  the  following  order  of  increas- 
ing precedence: 

logicaLoperator  ::=  and  | or  | xor 

relationaLoperator  ::=  = | /=  | < | <=  | > | >= 

adding_operator  ::=  + | - | & 

unary_operator  ::=  + | - | not 

multiplying_operator  ::=  * I / I mod 

exponentiating_operator  ::=  ** 


--  number 

— aggregate  array  value 

— value  of  a variable 
--  predefined  attribute 

--  function  subprogram  call 

— qualified  expression 

— parenthesized  expression 
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For  a sequence  of  operators  of  the  same  precedence  level,  evaluation  proceeds  in  textual  ordei 
from  left  to  right,  or  in  any  order  giving  the  same  result.  The  primaries  ot  an  expression  are  also 
evaluated  in  textual  order  All  primaries  are  evaluated  and  all  operations  are  performed. 

The  operands,  result  types,  and  the  meaning  of  the  predefined  operators  are  given  below  Note 
that  some  operations  may  result  in  exception  conditions  for  some  values  of  the  operands  (see 
chapter  1 1)  Real  expressions  sre  not  necessarily  calculated  with  exactly  the  specified  accuracy 
(precision  or  delta),  but  the  accuracy  used  will  be  at  least  as  good  as  that  specified. 


Examples  of  precedence 

not  SUNNY  or  WARM 
X > 4.0  end  Y > 0.0 

-4.0*A»*2 

Y**(-3I 
A / B » C 


— same  as  (not  SUNNY)  or  WARM 

— same  as  (X  > 4.0)  end  (Y  > 001 

— same  as  -(4.0  * (A**2)l 

— parentheses  are  necessary 

— same  as  (A/B)*C 


4.5.1  Logical  Operators 


Logical  operators  are  applicable  to  boolean  values  and  to  one  dimensional  arrays  of  boolean  values 
having  the  same  number  of  components.  The  operations  on  arrays  sre  performed  on  a component 
by  component  basis. 


Operator 

Operation 

Operand  Type 

Result  Type 

and 

conjunction 

BOOLEAN 
boolean  array  type 

BOOLEAN 
same  array 

type 

or 

inclusive  disjunction 

BOOLEAN 
boolean  array  type 

BOOLEAN 
same  array 

type 

xor 

exclusive  disjunction 

BOOLEAN 
boolean  array  type 

BOOLEAN 
same  array 

type 

4.5.2  Relational  and  Membership  Operators 


The  relational  operators  have  operands  of  the  same  type  and  return  boolean  values  Note  that 
equality  and  inequality  are  defined  for  any  two  objects  of  the  same  type  (unless  the  type  is  a 
restricted  type,  see  7.4). 
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Operator 

Operation 

Operand  Type 

Result  Type 

= /= 

equality  and 
inequality 

any  type 

BOOLEAN 

< <= 

test  for 

any  scalar 

BOOLEAN 

> >= 

ordering 

type 

Equality  for  the  discrete  types  is  equality  of  the  values.  For  a floating  (or  fixed)  point  type  T,  if  two 
values  differ  by  less  than  T'SMALL  (or  T'DELTA),  then  the  result  delivered  by  a relational  operator 
is  implementation  defined.  Equality  for  array  and  record  types  is  equality  of  the  components,  as 
given  by  the  predefined  operators.  Hence,  this  operation  is  unchanged  by  any  redefinition  of 
equality  on  the  component  types  involved.  Two  access  values  (see  3.8)  are  equal  if  they  designate 
the  same  dynamically  allocated  object. 


The  inequality  operator  gives  the  complementary  result  to  the  equality  operator. 

The  membership  operators  in  and  not  in  test  for  membership  of  a value  of  any  type  within  a cor- 
responding range,  subtype,  or  constraint.  These  operators  return  a boolean  value  and  have  the 
same  precedence  as  the  relational  operators. 

Examples: 

X /=  Y — with  real  X and  Y,  is  implementation  defined 

MY_CAR  = null  --  true  if  MY_CAR  has  been  set  to  null 

MY.CAR  = YOUR-CAR  --  true  if  sharing  one  car 

MY_CAR.aH  = YOUR_CAR.aH  - true  if  the  two  cars  are  identical 


I not  in  1 ..  10 

TODAY  in  WEEK.DAY 

TODAY  in  DAY  rang*  MON  ..  FRI 

0.1  = FRACI0.2) 


range  check 
subtype  check 
same  subtype  check 

qualification  necessary  to  define  the  type 


4.5.3  Adding  Operators 

The  adding  operators  + and  - return  a result  of  the  same  type  as  the  operands. 


Operator 

Operation 

Operand  Type 

Result 

Type 

+ 

addition 

numeric  type 

same 

numeric  type 

- 

subtraction 

numeric  type 

same 

numeric  type 

& 

catenation 

one  dimensional 
array  type 

same 

array  type 

For  real  types,  the  accuracy  of  the  result  is  the  accuracy  of  the  operand  type. 
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I he  adding  operator  & (catenation)  is  applied  to  two  operands  of  an  array  type  which  has  been 
declared  to  be  one  dimensional  and  whose  index  is  specified  by  a type  mark.  The  result  is  an  array 
of  the  same  type.  (Note  that  an  expression  of  the  component  type  is  regarded  as  a one  component 
array  of  this  type)  For  strings,  this  operation  results  in  conventional  string  catenation. 

For  all  numeric  types,  the  exception  RANGE_ERROR  is  raised  it  the  result  value  is  outside  the 
range  of  the  result  type.  The  exception  OVERFLOW  is  raised  if  the  result  value  is  beyond  the 
implemented  limits. 

Examples 

Z + 0. 1 — addition  is  that  of  the  type  of  Z,  which  must  be  real 

A & BCD’  — catenation  ot  a character  with  a stnng 


4.5.4  Unary  Operators 


Unary  operators 

are  applied  to  a 

single  operand  and 

return  a result  of  the  < 

Operator 

Operation 

Operand  Type 

Result  7 ype 

+ 

identity 

numeric  type 

same  numeric  type 

- 

negation 

numeric  type 

same  numeric  type 

ntrt 

logical  negation 

BOOLEAN 

BOOLEAN 

boolean  array  type 

same  array  type 

The  operator  not  can  also  be  applied  to  arrays  of  boolean  values  on  a component  by  component 
basis,  just  as  for  logical  operators. 

The  exceptions  RANGE_ERROR  and  OVERFLOW  can  be  raised  by  the  negation  operation,  just  as 
for  the  subtraction  operation. 


4.5.5  Multiplying  Operators 

The  operators  * and  / for  integer  and  floating  point  values  and  the  operator  mod  tor  mtegei  values 
return  a result  of  the  same  type  as  the  operands. 


Operator 

Operation 

Operand  Type 

Result  Type 

* 

multiplication 

integer 

same  integer  type 

floating 

same  floating  type 

/ 

integer  division 

integer 

same  integer  type 

floating  division 

floating 

same  floating  type 

mod 

modulus 

integer 

same  integer  type 

L 
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Integer  division  and  modulus  are  defined  by  the  relation 
A iABI.B  ♦ (A  mod  B) 

where  IA  mod  B)  has  the  sign  of  A and  an  absolute  value  less  than  the  absolute  value  of  B Inteoer 
division  satisfies  the  identity 

( Al'B  -<A/B)  =.  A/l-B) 

For  fined  point  values  the  following  multiplication  and  division  operations  are  provided.  The  types 
of  the  left  and  right  operands  are  denoted  by  L and  R. 


Operator 

Operation 

Operand 

L 

Type 

R 

Result  Type 

• 

multiplication 

fixed 

integer 

fixed 

integer 

fixed 

fixed 

same  as  L 
same  as  R 
universal  fixed 

/ 

division 

fixed 

fixed 

integer 

fixed 

same  as  L 
universal  fixed 

Integer  multiplication  of  fixed  point  values  is  equivalent  to  repeated  addition  and  hence  is  an 
accurate  operation.  Division  of  a fixed  point  value  by  an  integer  does  not  involve  a change  in  type 
but  is  approximate. 

Fixed  point  multiplication  may  yield  a value  of  an  arbitrary  accuracy  (denoted  by  universal  fixed  in 
the  table).  The  result  must  be  qualified  (see  4.6)  to  ensure  that  the  accuracy  of  the  computation  is 
explicitly  controlled.  The  same  considerations  apply  to  division  of  a fixed  point  value  by  another  fix- 
ed point  value. 

All  multiplying  operations  can  raise  the  exceptions  RANGE_ERROR,  OVERFLOW  or 
UNDERFLOW.  The  operations  / and  mod  give  the  exception  DIVIDE_ERROR  when  the  right 
operand  is  zero. 

Examples: 

I : INTEGER  :=  1; 

J : INTEGER  :=  2; 

K : INTEGER  :=  3; 

X MY_FLOAl  digits  6 :=  1.0; 

Y : MY_FLOAT  digits  6 :=  2.0; 

F : FRAC  delta  0.0001  :=  0.1; 

G : FRAC  delta  0.0001  :=  0.1; 
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t K/tressron 


Value 


Result  T ype 


UJ 

? 

ms 

1 

and  J l.o  INTEG1R 

K/J 

1 

stimti 

MS 

K 

and  J.  le  INTEGER 

K mod  J 

1 

MS 

K 

and  J in  INTEGER 

X/Y 

Oft 

sump 

MH 

X 

and  Y.  io  MY  F 1 OA1 

F/? 

0 0‘» 

sitmtt 

MS 

F. 

I a FRAG 

3.F 

03 

namti 

MS 

F. 

in.  FRAC 

F.G 

0.0 1 

universal 

fitted  qunllficatiort  needed 

t RAC(F.G) 

0 01 

given 

by 

qualification  i e 1 UAL". 

MV  HOAHJUY 

4.0 

MY  FLOAT 

qualification  o*  J 

converts  Its  value  tn  FI  OAT 


4.5.6  Exponentiating  Operator 


Operator  Operation 

Operand 

Type 

Result  Ty, rie 

L 

R 

♦ » exponentiation 

integer 

positive  integer 

same  as  1 

floating 

integei 

xante  as  L 

Exponent  In  t Ion  of  an  operand  by  n positivo  oxponnnt  is  nquivelent  to  repeated  multiplication  las 
Indicated  by  the  exponent)  of  the  operand  by  itself.  Foi  a floating  operand  the  exponent  can  be 
negative  In  which  case  the  value  Is  the  reciprocal  of  the  value  with  the  positive  exponent  This 
operation  can  rnise  the  OVERFLOW  DIVIDE  ERROR,  01  RANGE  ERROR  exception. 


4.6  Qualified  Expressions 

A qualified  expression  is  used  to  slate  the  type  of  an  expression  explicitly,  to  constrain  an  oxpres 
sion  to  a given  subtype,  or.  If  neither  case  applies,  to  convert  an  expression  to  another  type 

qualified  expression 

type  mnrkiaxpre salon)  | type  mark  aggi agate 


4.6.1  Explicit  Type  or  Subtype  Specification 

flte  same  literal  may  appear  in  several  types;  it  is  then  said  to  be  overloaded,  lit  these  cases  anti 
whenevei  the  type  of  a literal  or  aggregate  is  not  known  from  the  context  a qualified  expression 
must  be  used  to  state  the  type  explicitly 
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In  particular,  an  overloaded  literal  must  be  qualified  in  a subprogram  call  to  an  overloaded  sub 
program  that  cannot  be  identified  on  the  basis  of  remaining  parameter  or  result  types,  in  a 
relational  expression  where  both  operands  are  overloaded  literals,  or  in  an  array  or  loop  parameter 
range  where  both  bounds  are  overloaded  enumeration  literals. 

Explicit  type  specification  is  also  used  to  specify  the  result  type  of  fixed  point  multiplication  and 
division,  to  specify  which  one  of  a set  of  overloaded  parameterless  functions  is  meant,  or  to  con 
strain  a value  to  a given  subtype. 

Examples : 

type  MASKING_CODE  is  (FIX.  DEC.  EXP,  SIGNIF): 
type  INSTR_CODE  is  (FIX.  CLA,  DEC.  TNZ.  SUB); 

PRINT  (MASKING_CODE(DEC)>;  DEC  is  of  type  MASKING_CODE 

PRINT  (INSTR.-CODE(DEC));  - DEC  is  of  type  INSTR.CODE 

I in  INSTR_CODE(FIX)  ..  INSTR_CODE(DEC)  qualification  needed 

I in  INSTR.CODE  range  FIX  . DEC  qualification  given  by  the  context 


4.6.2  Type  Conversions 


For  numeric  expressions,  a qualified  expression  may  specify  a numeric  type  that  is  different  from 
the  type  of  the  expression.  In  this  case,  the  value  of  the  expression  is  converted  to  the  named  type 
With  conversions  involving  real  types,  the  converted  value  is  within  the  accuracy  of  the  specified 
type. 

Examples  of  numeric  type  conversion: 

REAl.(2*l)  --  value  is  converted  to  floating  point 

INTEGER!  1.6)  - value  is  2 

INTEGERI-0.4)  - value  is  0 

Explicit  conversion  is  allowed  between  objects  of  derived  types.  The  conversion  may  result  in  a 
change  of  representation,  as  described  in  chapter  13.  Explicit  conversion  is  also  allowed  between 
array  types  if  the  index  types  for  each  dimension  are  the  same  or  derived  from  each  other  and  if  the 
component  types  are  the  same  or  derived  from  each  other.  Conversion  involving  an  access  type 
relates  to  the  type  of  the  accessed  objects. 

Example  of  conversion  between  derived  types 

type  A_FORM  is  new  B_FORM; 

X ; A_FORM: 

Y ; B .FORM; 

X A._FORM(Y); 
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4.7  ANocalo re 

An  allocator  specifies  the  dynamic  creation  of  an  object  and  the  yeneration  of  an  access  value  that 
designates  the  object. 

allocator  new  qualified,  expression 

The  object  created  by  the  allocator  is  initialized  with  the  value  of  the  uxprossion  which  is  qualified 
by  the  name  of  the  access  type 

t samples . 

ELEMENT  new  LIST  .iTEMIVALUE  > 0.  SUCC  o>  null  PHEl)  ^ null) 

DOUBLE  :«  new  PERSONIME.a*). 


4.8  Static  Expressions 


d°", "°'  <,“P*"d  °"  computed  ..lee.  ol 

- 


(a)  literals 


'bl  eygreyates  whose  components  are  static  expressions 

(c)  constants  initialized  by  static  expressions 

Id)  predefined  operators,  functions  and  attributes 

(e)  qualified  static  expressions 

If)  indexed  and  selected  components  of  constants 
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5.  Statements 


1 


Statements  cause  actions  to  be  performed  when  executed.  A statement  may  be  simple  or  com- 
pound. A simple  statement  contains  no  other  statement.  A compound  statement  may  contain  sim- 
ple statements  and  other  compound  statements. 

sequence_of_statements  ::=  (statement) 

statement  ::= 

simple_statement  | compound_statement 
| <<identifier>>  statement 

simple_statement  ::= 

assignment_statement 
| exit_statement 
| goto_statement 
| initiate  .statement 
| raise_statement 
| code_statement 

compound_statement 

if_statement  | case_statement 

| loop_statement  | accept_s tatement 
| select_statement  | block 

A statement  may  be  labeled,  with  an  identifier  enclosed  by  double  angle  brackets,  e g. 
<<HERE>>.  Labelr  are  used  in  exit  and  goto  statements.  Within  the  sequence  of  statements  of  a 
subprogram  or  module  body,  different  labels  must  have  different  identifiers. 

Execution  of  a null  statement  has  no  other  effect.  Blocks  are  described  in  the  next  chapter.  Initiate, 
delay,  abort,  accept,  and  select  statements  are  described  in  chapter  9 (Tasks)  Raise  statements 
are  described  in  chapter  1 1 (Exceptions).  Code  statements  are  described  in  section  13.8  (Machine 
Code  Insertions).  The  remaining  statements  are  described  here. 

The  statements  in  a sequence  of  statements  are  executed  in  succession  unless  an  exception  is 
raised  or  unless  an  exit,  return,  or  goto  statement  is  executed. 


5.1  Assignment  Statements 

An  assignment  statement  replaces  the  current  value  of  a variable  with  a new  value  specified  by  an 
expression. 

assignment_statement  ::=  variable  :=  expression; 
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subprogram_call_statement 

return_statement 

assert_statement 

delay_statement 

abort_statement 

null; 


The  variable  and  the  expression  must  be  of  the  same  type  and  the  value  of  the  expression  must  be 

compatible  with  any  range,  index,  or  discriminant  constraint  applicable  to  the  variable.  If  the  con 

straints  are  not  checked  during  compilation,  an  execution  time  check  is  performed  and  raises  an 
exception  if  it  fails  (the  check  may  be  omitted  if  the  corresponding  exception  is  suppressed  see 
11.6). 

Examples : 

KEY_VALUE  :=  MAX_VALUE  - 1; 

SHADE  :=  BLUE; 

Examples  of  constraints. 

I.  J : INTEGER  range  1 . 10; 

K ; INTEGER  range  1 ..  20; 

I :=  J:  — identical  ranges 

K :=  J;  — compatible  ranges 

J K;  — can  only  be  checked  during  execution 

- and  may  raise  the  RANGE_ERROR  exception 


5.1.1  Array  and  Slice  Assignments 


For  an  assignment  to  an  array  or  to  an  array  slice  variable,  the  expression  must  denote  a value  with 
the  same  number  of  components.  For  slice  assignments  where  the  slice  value  refers  to  the  same 
array  as  the  slice  variable,  overlapping  of  index  ranges  is  forbidden  and  raises  the  exception 
OVERLAP_ERROR. 

Examples. 

A : STRINGIO  . 30); 

B ; STRING!  1 ..  31); 

A :=  B;  — same  number  of  elements 

A(1  10)  :=  A(  1 1 ..  20);  — non  overlapping  ranges 

A(1  ..  5)  :=  "JAMES";  — same  number  of  elements 


5.1.2  Record  Assignments 


For  an  assignment  to  a record  variable  declared  with  a specified  discriminant  value,  the  assigned 
record  value  must  have  the  prescribed  discriminant  value.  The  discriminant  of  a record  denoted  by 
an  access  variable  cannot  be  altered,  not  even  by  a complete  record  assignment. 


5-2 


Examples-. 


DISK_1,  DISK_2  : PERIPHERAUUNIT  =>  DISK); 

0ISK_1  :=  (STATUS  =>  OPEN.  UNIT  =>  DISK.  CYLINDER  =>  1 TRACK  =>  1) 
DISK_2  ;=  DISK_1 ; 


5.2  Subprogram  Calls 


A subprogram  call  invokes  execution  of  a subprogram  body.  The  call  specifies  the  association  of 
any  actual  parameters  with  formal  parameters  of  the  subprogram.  An  actual  parameter  is  either  a 
variable  or  the  value  of  an  expression. 

subprogram_call_statement  ::=  subprogram_call; 
subprogram_call  ::= 

subprogram_ name  |(parameter_association  (,  parameter_association|)| 

parameter_association  ::= 

|formal_parameter  :=|  actual_parameter 
(formaLparameter  = :]  actual_parameter 
| |formal_parameter  :=:]  actual_parameter 

formal_parameter  ::=  identifier 

actual_parameter  ::=  expression 

Actual  parameters  may  be  passed  in  positional  order  (positional  parameters)  or  by  explicitly  nam- 
ing the  corresponding  formal  parameters  (named  parameters).  For  positional  parameters,  the 
actual  parameter  corresponds  to  the  formal  parameter  with  the  same  position  in  the  formal 
parameter  list.  For  named  parameters,  the  corresponding  formal  parameter  is  explicitly  given  in  the 
call.  Named  parameters  may  be  given  in  any  order. 

Positional  parameters  and  named  parameters  may  be  used  in  the  same  call  provided  that 
positional  parameters  occur  first  at  their  normal  position,  i.e.  once  a named  parameter  is  used,  the 
rest  of  the  call  must  use  only  named  parameters. 

Examples: 

RIGHT_SHIFT; 

TABLE_MANAGER.INSERT(E); 

SEARCH_STRING(STRING,  CURRENT_POSITION,  NEW_POSITION); 

PRINT_HEADER(PAGES  :=  128,  HEADER  :=  TITLE,  CENTER  :=  TRUE); 
REORDER_KEYS(NUM_OF_ITEMS,  KEY_ARRAY  :=:  RESULT_TABLE); 
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5.2.1  Actual  Parameter  Associations 


There  are  three  forms  for  specifying  actual  parameters 

(a)  Input  parameter  association 

|formal_para meter  :=)  actuaLparameter 

The  corresponding  formal  parameter  must  have  the  mode  in.  Its  value  is  provided  by  the 
actual  parameter. 

(b)  Output  parameter  association 

IformaLparameter  =:|  actuaLparameter 

The  corresponding  formal  parameter  must  have  the  mode  out.  Its  value  is  assigned  to  the 
actual  parameter  as  a result  of  the  execution  of  the  subprogram. 

(c)  Input-output  parameter  association 

|formal_parametcr  :=:|  actuaLparameter 

The  corresponding  formal  parameter  must  have  the  mode  in  out.  Within  the  subprogram,  the 
formal  parameter  permits  access  and  assignment  to  the  corresponding  actual  parameter. 

An  expression  used  as  an  in  parameter  is  evaluated  before  the  call.  An  expression  used  as  an  out  or 
in  out  actual  parameter  must  be  a variable  or  a qualified  variable.  The  identity  of  a variable  out  or  in 
out  actual  parameter  which  is  a selected  component  or  an  indexed  component  is  established 
before  the  call. 


5.2.2  Omission  of  Actual  Parameters 


An  in  parameter  may  be  omitted  from  the  actual  parameters  if  the  subprogram  declaration 
specifies  a default  value  for  the  corresponding  formal  parameter.  In  such  cases,  any  remaining 
actual  parameters  must  be  named. 

Example  of  procedure  with  default  values: 

procedure  ACTIVATE!  PROCESS  : in  PROCESS_NAME; 

AFTER  : in  PROCESS_NAME  :=  NO_PROCESS; 

WAIT  : in  TIME  :=  0.0; 

, PRIOR  ; in  BOOLEAN  :=  FALSE); 

Examples  of  its  call: 

ACTIVATE(X); 

ACTIVATED.  AFTER  :=  Y); 

ACTIVATED,  WAIT  :=  50.SEC0NDS,  PRIOR  :=  TRUE); 
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5.2.3  Restrictions  on  Subprogram  Calls 


The  type  and  constraint  of  each  actual  parameter  must  be  consistent  with  those  of  the  cor- 
responding formal  parameter,  as  for  assignment.  To  prevent  aliasing  (i.e.  multiple  access  to  tlv* 
same  variable),  a variable  which  is  used  as  an  actual  out  or  in  out  parameter  may  not  be  used  as 
another  parameter  of  the  same  call.  For  this  rule,  any  variable  that  is  not  local  to  the  subprogram 
body  is  considered  as  an  implicit  in  parameter  if  its  value  is  read,  and  is  considered  as  an  in  out 
parameter  if  it  is  directly  or  indirectly  updated  as  a result  of  the  call. 


5.3  Return  Statements 

A return  statement  terminates  execution  of  a subprogram. 
return_statement  return  (expression  |; 

A return  statement  can  only  appear  in  the  sequence  of  statements  of  a subprogram.  A return  state- 
ment must  not  appear  in  an  accept  statement.  For  functions  or  value  returning  procedures,  a return 
statement  must  include  an  expression  whose  value  is  the  result  of  the  subprogram. 

Examples : 

return; 

return  KEY_VALUE(LAST_INDEX); 


5.4  If  Statements 


An  if  statement  effects  the  choice  of  a sequence  of  statements  based  on  the  truth  value  of  one  or 
more  conditions.  The  expressions  appearing  in  conditions  must  be  of  the  predefined  type 
BOOLEAN. 

if_statement  ::= 

if  condition  than 
sequence_of_statements 
( elsif  condition  than 

sequence_of_statements| 
l else 

sequence_of_statements| 

and  if; 

condition  ::= 

expression  (and  than  expression) 

| expression  (or  else  expression) 


Execution  of  an  if  statement  results  in  evaluation  of  the  conditions,  one  after  the  other  (treating  i 
final  else  as  elsif  TRUE  then),  until  one  evaluates  to  TRUE;  then  the  corresponding  sequence  of 
statements  is  executed.  If  none  of  the  conditions  evaluates  to  TRUE,  none  of  the  sequences  of 
statements  is  executed. 

Examples. 

M MONTH  = DECEMBER  end  DAY  = 31  then 
MONTH  :=  JANUARY; 

DAY  :=  1; 

YEAR  :=  YEAR  + 1; 

end  if; 

H INDENT  then 

CHECK_LEFT_MARGIN; 

LEFT.SHIFT; 
elsif  UNDENT  then 
RIGHT_SHIFT; 
else 

CARRIAGE_RETURN; 

CONTINUE_SCAN; 

end  if; 

«f  MY_ CAR. OWNER. VEHICLE  /=  MY_CAR  then 
FAIL  ('INCORRECT  RECORD"); 

end  if. 


5.4.1  Short  Circuit  Conditions 


A condition  may  appear  as  a sequence  of  boolean  expressions  separated  by  and  then.  In  such  a 
case,  evaluation  of  the  constituent  expressions  proceeds  in  textual  order  until  one  evaluates  to 
FALSE,  in  which  case  the  value  of  the  condition  is  FALSE;  the  condition  is  true  only  if  all  expres- 
sions evaluate  to  TRUE.  Similarly,  for  expressions  separated  by  or  oiso.  evaluation  stops  as  soon  as 
an  expression  evaluates  to  TRUE,  in  which  case  the  value  of  the  condition  is  TRUE;  the  condition  is 
false  only  if  all  expressions  evaluate  to  FALSE. 

Examples 

if  MY_CAR. OWNER  /=  null  and  than  MY_CAR.OWNER.AGE  < 18  than 
MINOR  :=  TRUE, 

and  if; 

H 1 = 0 or  alaa  A(l)  = HIT_ VALUE  than 
return; 
and  if; 
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5.5  Cm#  Statements 


A case  statement  selects  and  executes  one  of  several  alternative  sequences  of  statements.  The 
selection  is  based  on  the  value  of  an  expression,  of  a discrete  type,  given  at  the  head  of  the  case 
statement. 

case_statement  ::= 
case  expression  of 

Iwhen  choice  ||  choice)  =>  sequence_of_statements| 

and  case: 

Each  alternative  is  preceded  by  a list  of  choices  specifying  the  values  for  which  the  alternative  is 
executed.  Choices  given  in  case  statements  follow  the  same  rules  as  choices  given  in  component 
associations  for  array  aggregates  (see  3.6.2).  Thus,  each  possible  value  of  the  type  or  subtype  of 
the  expression  must  be  given  for  one  and  only  one  alternative;  the  choice  other*  can  be  given  as 
the  choice  for  the  last  alternative  to  cover  all  values  not  given  in  previous  choices.  Note  that  it  is 
always  possible  to  use  a qualified  expression  to  limit  the  number  of  choices  that  need  be  given 
explicitly. 


Examples'. 


cim  SENSOR  of 
when  ELEVATION 
when  AZIMUTH 
when  DISTANCE 
when  others 
end  case: 


= > RECORD_ELEVATION  (SENSOR_VALUE) 
= > RECORD_AZIMUTH  (SENSOR.VALUE) 
= > RECORD_DISTANCE  (SENSOR_VALUE) 

=>  null; 


case  TODAY  of 

when  MON 

=> 

when  FRI 

= > 

when  TUE  .. 

THU 

=> 

when  SAT  .. 

SUN 

= > 

COMPUTE_INITIAL_BALANCl; 

COMPUTE_CLOSING_BALANCE; 

GENERATE_REP0RT(T0DAY);1 

null;  ! 


case  BIN_NUMBER((I  mod  4)  + 1)  of 
when  1 =>  UPDATE_BIN(1); 
when  2 =>  UPDATE_BIN<2); 
when  3 | 4 => 

EMPTY_BIN(1); 

EMPTY_BIN(2); 
end  case; 


5.6  Loop  Statements 


A loop  statement  specifies  that  a sequence  of  statements  in  a basic  loop  is  to  be  executed 
repeatedly  zero  or  more  times.  Execution  is  terminated  either  when  the  iteration  specification  of 
the  loop  is  exhausted  or  when  an  exit  statement  within  the  basic  loop  is  executed. 
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loop_statement 


[iteration  ..specification!  basic_loop 


bastc_loop 

loop 

sequence_of_statements 
ond  loop  [identifier!: 

iteration_specification  ::=  _ 

for  loop_parameter  in  [fovoraol  discrete_range 
I while  condition 

loop  .parameter  identifier 

In  a loop  statement  with  a while  clause,  the  condition  is  evaluated  and  tested  before  each  execu 
tion  of  the  basic  loop.  If  the  while  condition  is  TRUE  the  loop  is  executed,  if  FALSE  the  loop  state- 
ment is  terminated. 

In  a loop  statement  with  a for  clause,  the  discrete  range  is  evaluated  only  once,  before  execution  of 
the  loop  statement.  The  loop  parameter  is  implicitly  declared  as  a local  variable  whose  type  is  that 
of  the  elements  in  the  discrete  range  On  successive  loop  iterations,  the  loop  parameter  is  succes- 
sively assigned  values  from  the  specified  range.  The  values  are  assigned  in  increasing  order  unless 
the  reserved  word  reverse  is  present,  in  which  case  the  values  are  assigned  in  decreasing  order. 

If  the  range  of  a for  loop  is  empty,  the  basic  loop  is  not  executed.  Within  the  basic  loop,  the  loop 
parameter  acts  as  a constant.  Hence  the  loop  parameter  may  not  be  changed  by  an  assignment 
statement,  nor  may  it  be  given  as  an  out  or  in  out  parameter  of  a subprogram  call. 

If  a loop  is  a labeled  statement,  the  label  identifier  must  be  repeated  at  the  end  of  the  loop  after  the 
reserved  words  ond  loop. 

Examples. 

\ 

white  BID(I). PRICE  < CUT_OFF.PRICE  loop 
RECOR  D_BI  D(BI  D(I).PRICE); 

I :=  I + 1; 

end  loop 

white  NEXT  /=  HEAD  loop 

SUM  :=  SUM  + NEXT.  VALUE: 

NEXT  :=  NEXT.SUCC; 

end  loop; 

for  I in  BUFFER'FIRST  . BUFFER’LAST  loop  — valid  even  with  empty  range 
if  BUFFER(I)  /=  * ' then 
PUT(BUFFERd)); 

end  if; 
end  loop; 
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5.7  Exit  Statements 


An  exit  statement  causes  explicit  termination  of  an  enclosing  loop. 

exil_statement  ::=  exit  (identifier!  I when  condition); 

The  loop  exited  is  the  innermost  loop,  unless  the  exit  statement  identifies  the  label  of  an  enclosing 
loop,  in  which  case  the  named  loop  is  exited.  The  exit  statement  may  contain  a condition,  in  which 
case  termination  occurs  only  if  its  value  is  TRUE.  An  exit  statement  may  only  appear  within  a loop. 
An  exit  statement  cannot  transfer  control  out  of  a subprogram,  module,  accept  statement,  or 
exception  handler. 

Example. 

for  I in  1 ..  MAX.NUMJTEMS  loop 
GET_NEW_ITEM(NEW_ITEM); 

MERGE_ITEM(NEW_ITEM,  STORAGE.FILE); 
exit  when  NEWJTEM  = TERMINALJTEM; 

end  loop; 

<<MAIN_CYCLE>> 

loop 

— initial  statements 

exit  MAIN.CYCLE  when  FOUND; 

— final  statements 
end  loop  MAIN.CYCLE; 


5.8  Goto  Statements 


ie  execution  of  a goto  statement  results  in  an  explicit  transfer  of  control  to  another  statement. 
goto_statement  ::=  goto  identifier; 

The  statement  to  which  control  is  transferred  must  be  labeled  with  the  same  identifier.  The 
designated  statement  and  the  goto  statement  must  both  be  within  the  same  subprogram,  module, 
or  accept  statement. 

A goto  statement  cannot  transfer  control  from  outside  into  a compound  statement,  block,  sub- 
program, module,  accept  statement,  or  exception  handler.  It  may  transfer  control  from  one  of  the 
sequences  of  statements  of  an  if  statement  or  a case  statement  to  another. 

A goto  statement  cannot  transfer  control  out  of  a subprogram,  module,  accept  statement,  or 
exception  handler. 


Example. 


<<COMPARE>> 
if  A(l)  < ELEMENT 
if  LEFT(I)  /=  0 then 
I :=  LEFT(I); 

goto  COMPARE; 
end  if; 

— some  statements 

end  if; 


’ r 


5.9  Assert  Statement 


An  assert  statement  states  that  a condition  must  hold  whenever  control  reaches  that  point  in  the 
program. 


assert_statement  ;;= 


condition; 


awbt  e!Snn * an  asse't  statement  causes  the  evaluation  of  the  condition,  and  the  exception 
AbbERT_ERROR  is  raised  if  the  condition  is  false. 


Execution  of  assert  statements  may  be  omitted  when  the  exception  ASSERT_ERROR  is  suppres- 
sed by  a pragma  (see  1 1.6 ).  * 
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6.  Declarative  Part*.  Subprograms,  and  Blocks 


A declarative  part  contains  declarations  and  related  information  that  apply  over  a region  of 
program  text. 

A subprogram  is  an  executable  program  unit  that  is  invoked  by  a subprogram  call.  Its  definition  can 
be  given  in  two  parts:  a subprogram  declaration  defining  its  calling  convention,  and  a subprogram 
body  defining  its  execution. 

A block  allows  one  to  make  declarations  local  to  the  sequence  of  statements  where  they  are  used, 
without  introducing  a procedure.  A block  may  be  viewed  as  an  anonymous  procedure  implicitly 
called  at  the  place  of  its  definition. 


6. 1 Declarative  Parts 


Blocks,  subprograms,  and  modules  may  contain  declarative  parts. 
declarative_part 

[use_clause|  (declaration)  |representation_specification|  (body) 

body  |visibility_restriction|  unit_body  | body_stub 

unitjaody  ::=  subprogram_body  | module_specification  ( module_body 

The  successive  constituents  of  a declarative  part  are  elaborated  in  the  order  in  which  they  appear 
in  the  program  text.  Expressions  appearing  in  declarations  or  representation  specifications  (see  13) 
are  evaluated  during  this  elaboration.  A subprogram  must  not  be  called  within  such  an  expression 
if  the  subprogram  body  appears  later  in  the  declarative  part  In  particular,  these  rules  apply  to  for- 
mal parts  of  subprogram  specifications  and  to  constraints  of  objects,  types,  and  subtypes. 

The  body  of  a subprogram  or  module  declared  in  the  declarative  part  of  a block  or  subprogram 
must  be  provided  in  the  same  declarative  part.  The  body  of  a subp'ogram  or  module  declared  in  a 
module  specification  must  be  provided  in  the  corresponding  module  body.  If  the  body  of  such  a 
unit  is  a separately  compiled  subunit  (see  10.2)  it  must  be  represented  by  a body  stub  at  the  place 
where  it  would  otherwise  appear 

A declarative  part  can  also  contain  a use  clause  (see  8.4). 


I 
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6.2  Subprogram  Declaration* 


A subprogram  declaration  specifies  the  designator  of  a subprogram,  its  nature  (function  or  tub 
program).  Its  formal  parameters  (it  any)  and  the  type  of  any  returned  value 

subprogram  declaim  ion 

subprogram  specification 

I subprogram. nature  designator  la  generic  Instantiation 

subprogram  specification  : Igonarlc  clausal 

subprogram,  nature  designator  (formal  parti  I return  type  mmk  |conslraint|| 

subprogi am  nature  function  | procedure 

designator  ideniitiei  | character.. string 

formal  part  (parameter  declaration  |;  parnmatei  declaration  I) 
parameter  declaration 

identifier  list  mode  type  mark  (constraint)  I expression | 

mode  I ini  | out  I In  out 

A designator  that  is  a character  string  is  used  in  function  declarations  tor  overloading  operators  of 
the  language  Such  a string  must  denote  one  ot  the  existing  operator  symbols  (see  4.S) 

A subprogram  specification  including  a generic  clause  specifies  a generic  subprogram:  an  instance 
of  such  a generic  subprogram  is  declared  with  a subprogram  declaration  Including  a generic 
instantiation  (see  12). 


A parameter  declaration  or  constraint  on  the  result  cannot  contain  an  Identifier  declared  in  another 
parameter  declaration  of  the  same  formal  part 

t samples  of  subprogram  declarations: 

procedure  IHAVfcHSE.  THfcfc 

procedure  MIGHT  INDfcNI (MAHGIIM  out  LINfc  POSItlON) 
procedure  INCHtMfeNTlX  : in  out  INTEGER); 
procedure  HANOOVl  return  HEAL  range  10  10: 

function  COMMON  KHIMfc  (M.  N : INTLGEH)  return  INTEGER 
function  DOT.  PHOUUCI  (X.  Y VECTOR)  return  Ht Al 
function  (X.  Y MAIHIX)  return  MAIHIX; 

biotas 


All  subprograms  can  bo  called  recursively  and  are  reentrant. 
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6.3  Formal  Parameters 


The  formal  parameters  of  a subprogram  are  considered  local  to  the  subprogram  A parameter  has 
one  of  three  modes: 

in  The  parameter  acts  as  a local  constant  whose  value  is  provided  by  the 

corresponding  actual  parameter 

out  The  parameter  acts  as  a local  variable  whose  valtte  is  assigned  to  the  corres 
ponding  actual  parameter  as  a result  of  the  execution  ot  the  subprogram 

in  out  The  parameter  acts  as  a local  variable  and  permits  access  and  assignment  to 
the  corresponding  actual  parameter 

If  no  mode  is  explicitly  given,  the  mode  in  is  assumed  The  components  of  in  parameters  that  are 
arrays,  records,  or  objects  denoted  by  access  values  must  not  be  changed  by  the  subprogram 

For  in  parameters,  tho  parameter  declaration  may  also  include  a specification  of  a default  expres 
sion,  whose  value  is  implicitly  assigned  to  the  parameter  if  no  explicit  value  is  given  in  the  call.  This 
expression  is  evaluated  when  the  subprogram  specification  is  elaborated. 

For  all  modes,  access  to  the  actual  parameters  can  be  provided  either  throughout  the  execution  of 
the  subprogram  body  or  by  copying  the  corresponding  actual  parameter  before  the  call  (in 
parameters),  after  the  call  lout  parameters)  or  both  (in  out  parameters)  The  effect  of  a subprogram 
that  is  abnormally  terminated  by  the  occurrence  of  an  exception  is  undefined  its  actual  in  out  and 
out  parameters  may  or  may  not  have  been  updated 

In  the  absence  of  aliasing  (see  5.2.3)  the  effect  of  a subprogram  call  is  the  same  whether  or  not 
copying  is  used  for  parameter  passing,  unless  the  subprogram  execution  is  abnormally  terminated 
A program  that  relies  on  some  assumption  regarding  the  actual  mechanism  used  for  parameter 
passing  is  therefore  erroneous 

Examples  of  in  parameters  with  default  values: 

procedure  PRINT  HEADER!  PAGES  : in  INTEGER 

HEADER  in  LINE  BLANieLINE: 

CENTER  in  BOOLEAN  TRUE). 

procedure  ACTIVATE!  PROCESS  in  PROCESS_NAME: 

AFTER  : in  PROCESS._NAME  : NO  PROCESS: 

WAIT  In  REAL  . 0 0, 

PRIOR  in  BOOLEAN  FALSE) 


6.4  Subprogram  Bodies 


A subprogram  body  specifies  the  execution  of  a subprogram. 

subprogram  body  :: 

subprogram_specification  ia 
declarative  .part 

begin 

sequance_of_statementa 
I exception 

lexception.  handlerl  | 
end  Idesignatorl: 

The  subprogram  specification  provided  in  a subprogram  body  must  be  identical  to  the  specification 
given  in  the  corresponding  subprogram  declaration,  if  both  are  given.  A subprogram  declaration 
must  be  given  if  the  subprogram  is  defined  in  the  visible  part  of  a module,  or  if  it  is  called  by  other 
subprogram  or  module  bodies  that  appear  before  its  own  body.  Otherwise,  it  can  be  omitted  and 
the  specification  appearing  in  the  body  acts  as  a subprogram  declaration.  The  elaboration  of  a sub- 
program body  consists  of  the  elaboration  of  its  specification  unless  the  latter  elaboration  has 
already  been  done. 

Upon  each  call  to  a subprogram,  the  association  between  actual  and  formal  parameters  is 
established  (see  5.2),  the  declarative  part  of  the  body  is  elaborated,  and  the  statements  of  the  body 
are  executed.  Upon  completion  of  the  body,  assignment  to  out  and  in  out  actual  parameters  is 
completed,  if  necessary  (see  6.3),  and  then  return  is  made  to  the  caller.  A subprogram  body  may 
contain  exception  handlers  to  service  exceptions  occurring  during  its  execution  (see  1 1 ). 

The  optional  designator  at  the  end  of  the  subprogram  body  must  repeat  the  designator  of  the  sub 
program  specification. 

Example  of  subprogram  body. 

procedure  PUSH(E  : in  ELEMENT  .TYPE;  S . in  out  STACK)  is 

begin 

if  S. INDEX  S.SIZE  then 

raise  STACK.  OVER  FLOW; 

else 

S. INDEX  : S INDEX  ► 1; 

S.SPACEIS. INDEX)  : E; 
end  if: 
end  PUSH; 

Notes. 

A subprogram  body  may  be  expanded  in  line  at  each  call  if  its  declarative  part  includes  the 
declarative  pragma: 

pragma  INLINE. 

The  meaning  of  a subprogram  is  not  changed  by  the  pragma  INLINE,  which  is  merely  a recommen- 
dation to  the  compiler.  Thus,  an  inline  subprogram  could  be  recursive  or  separately  compiled. 
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6.5  Function  Subprograms 

A function  is  a subprogram  that  computes  a value.  A function  can  only  have  in  parameters  and 
must  contain  a return  clause  specifying  the  type  of  its  returned  value.  The  statement  list  in  the 
function  body  must  include  one  or  more  return  statements  specifying  the  returned  value.  An 
attempt  to  leave  a function  otherwise  than  by  a return  statement  (i.e.  by  reaching  the  final  and) 
causes  a NO_VALUE_ERROR  exception  to  be  raised. 

Side  effects,  e.g.  assignments  to  non-local  variables,  are  not  allowed  within  functions,  whether 
directly,  or  indirectly  through  other  subprogram  calls.  Hence,  if  function  calls  occur  in  expressions, 
they  can  be  rearranged  in  any  order  consistent  with  the  properties  of  the  operators. 

If  a parameter  belongs  to  an  access  type,  the  parameter  must  be  viewed  as  providing  access  to  the 
complete  collection  of  dynamically  allocated  objects.  For  functions,  this  collection  is  considered  as 
an  implicit  in  parameter.  As  a consequence,  within  the  function  body  there  can  be  no  alteration  *j 
any  object  designated  by  such  a parameter  or  designated  by  a local  variable  of  the  access  type. 
Similarly,  allocators  cannot  appear  in  a function  body. 

Value  returning  procedures  obey  rules  similar  to  those  of  functions:  a value  returning  procedure 
can  only  have  in  parameters,  its  declaration  must  contain  a return  clause,  and  its  body  may  only  be 
left  by  a return  statement.  However,  assignments  to  global  variables  are  permitted  within  value 
returning  procedures.  Calls  of  such  procedures  are  only  valid  at  points  of  the  program  where  the 
corresponding  variables  are  not  within  the  scope  of  their  declaration.  The  order  of  evaluation  of 
these  calls  is  strictly  that  given  in  the  text  of  the  program.  Calls  to  value  returning  procedures  are 
only  allowed  in  expressions  appearing  in  assignment  statements,  initializations,  and  procedure  cal- 
ls. 

Examples'. 

function  DOT_PRODUCT(X.  Y : VECTOR)  rotum  REAL  is 
SUM  : REAL  :=  0.0; 

begin 

assert  XFIRST  = Y'FIRST; 
assert  X LAST  = Y LAST; 
for  I in  X FIRST  ..  X'LAST  loop 
SUM  :=  SUM  + X(I)*Y(I); 
end  loop: 
return  SUM; 

end  DOT_PRODUCT; 

peckage  UNIQUE_NUMBER_GENERATOR  Is 

procedure  GENERATOR  return  INTEGER;  — value  returning  procedure 

end; 

package  body  UNIQUE_NUMBER_GENERATOR  is 

COUNT  : INTEGER  :=  0;  ~ COUNT  is  not  visible  where  GENERATOR  is  called 

procedure  GENERATOR  return  INTEGER  Is 

begin 

COUNT  :=  COUNT  + 1;  - side  effect  on  COUNT 

return  COUNT; 
end  GENERATOR: 

end  UNIQUE_NUMBER_GENERATOR; 
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6.6  Overloading  of  Subprograms 


The  same  subprogram  designator  can  be  given  in  several  otherwise  different  subprogram 
specifications;  it  is  then  said  to  be  overloaded.  The  declaration  of  an  overloaded  subprogram  does 
not  hide  a previous  subprogram  declaration  unless  the  order,  names,  modes,  and  types  of  the 
parameters,  and  the  result  type,  if  any,  are  identical  in  both  declarations  (a  default  expression  for 
an  in  parameter  is  ignored  here).  Such  redefinition  is,  of  course,  illegal  within  the  same  declarative 
part.  Overloaded  definitions  may.  but  need  not,  occur  in  the  same  declarative  part. 

A call  to  an  overloaded  subprogram  is  ambiguous  (and  therefore  illegal)  if  the  type,  mode  and 
name  information  derived  from  the  actual  parameter  associations  and  the  type  information 
required  for  the  result  are  not  sufficient  to  identify  exactly  one  over'oaded  specification. 
Ambiguities  may  be  resolved  by  the  use  of  a qualified  expression,  or  by  the  naming  of  parameters. 

Examples  of  overloaded  subprograms'. 

procedure  PUT(X  : INTEGER); 
procedure  PUT(X  . STRING); 

procedure  CHANGE(C  : COLOR), 
procedure  CHANGEIL  : LIGHT); 
procedure  CHANGEIF  : LIGHT): 

Example  of  calls : 

PUT(28); 

PUT(“no  possible  ambiguity  here"); 

CHANGEICOLOR(RED)); 

CHANGED  :=  RED); 

CHANGEIF  :=  RED): 

- CHANGE(RED)  would  be  ambiguous  since  RED  may  denote  a value  of  either  COLOR  or  LIGHT 
X ♦ 1.5  --  the  floating  or  fixed  point  type  of  X identifies  the  relevant  " + ' 


6.6.1  Overloading  of  Operators 


A function  named  by  a character  string  is  used  to  define  an  additional  meaning  for  an  operator.  The 
overloading  of  operators  is  identical  to  overloading  of  other  subprograms,  except  that  the  character 
string  must  denote  one  of  the  operators  in  the  language. 

Overloading  is  permitted  for  both  unary  and  binary  operators.  A unary  operator  can  only  be 
overloaded  as  a unary  and  a binary  as  a binary.  Overloading  does  not  change  the  precedence  of  an 
operator  An  overloading  of  a relational  operator  must  have  the  result  type  BOOLEAN.  The 
operator  /-  must  not  be  overloaded  explicitly,  since  every  overloading  of  the  operator  = results  in 
an  implicit  ovarloading  of  /-. 


Examples. 


function  *•*  (X,  Y : MATRIX)  return  MATRIX; 
function  (X,  Y : VECTOR)  return  VECTOR 

Notes: 

Good  usage  of  operator  overloading  should  preserve  their  mathematical  properties. 

6.7  Block* 


A block  introduces  a sequence  of  statements,  optionally  preceded  by  a governing  declarative  part. 

block 

I doctor* 

declarative_part| 

begin 

sequence_of_statements 
I exception 

I except  ion_handler  | ) 
end  |identifier|; 

Execution  of  a block  results  in  the  elaboration  of  its  declarative  part  followed  by  the  execution  of 
the  sequence  of  statements.  A block  may  also  contain  exception  handlers  to  service  exceptions 
occurring  in  the  block  (see  1 1).  If  a block  is  labeled,  the  optional  identifier  appearing  at  the  end  of 
the  block  must  repeat  the  label. 

Example  of  a labeled  block: 

<<SWAP>> 

declare 

TEMP  : INTEGER; 
begin 

TEMP  :=  V;  V :=  U;  U ;=  TEMP: 
end  SWAP; 
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7.  Module* 


A program  can  be  composed  of  program  units  of  three  kinds.  These  are  subprograms  and  two 
forms  of  modules,  package  modules  and  task  modules  This  chapter  describes  the  common 
properties  of  package  and  task  modules  and  the  few  specific  properties  of  package  modules.  The 
specific  properties  of  task  modules  are  described  in  Chapter  9. 

Modules  allow  the  specification  of  groups  of  logically  related  entities.  In  their  simplest  form 
modules  can  represent  pools  of  common  data  and  type  declarations.  In  addition,  modules  can  be 
used  to  describe  groups  of  related  subprograms  and  encapsulated  data  types,  whose  inner  work- 
ings are  concealed  and  protected  from  their  users. 


7.1  Module  Structure 


A module  is  generally  provided  in  two  parts:  a module  specification  and  a module  body  with  the 
same  identifier.  The  simplest  forms  of  modules,  those  representing  pools  of  data  and  types,  do  not 
require  a module  body. 

module_declaration  ::= 

[visibility _restriction|  module_specification 
| module_nature  identifier  [(discrete_range)|  i*  generic_instantiation; 

module_specification  ::= 
l generic_clause| 

module_nature  identifier  |(discrete_range)|  [is 
declarative_part 

[ private 

declarative_part[ 
and  [identifier!!; 

module_nature  ::=  package  | task 

module_body  ::= 

module.nature  body  identifier  is 
declarative_part 

( begin 

sequence_of_statements| 

( exception 

|exception_handler[| 
and  [identifier!; 

A module  specification  contains  a declarative  part  called  the  visible  part  and  an  optional 
declarative  part  called  the  private  part.  Elaboration  of  a module  declaration  results  in  the  elabora- 
tion of  these  declarative  parts  and  therefore  in  the  allocation  of  the  variables  of  the  module 
specification  and  the  assignment  of  any  initial  values. 


7-1 


A module  specification  with  a generic  clause  defines  a generic  module  Instances  of  generic 
modules  can  be  obtained  by  module  declarations  including  a generic  instantiation  (see  12). 

A module  declaration  may  include  a discrete  range  after  the  identifier  This  only  applies  to  task 
modules  and  the  identifier  then  denotes  a family  of  tasks. 

The  elaboration  of  a task  body  has  no  other  effect.  The  elaboration  of  its  declarative  part  and  the 
execution  of  its  sequence  of  statements  is  caused  by  the  execution  of  an  initiate  statement  (see 
9.3).  The  elaboration  of  a package  body  causes  the  elaboration  of  its  declarative  part  and  the 
execution  of  the  sequence  of  statements,  if  any.  These  statements  can  be  used  to  achieve  further 
initializations. 

Module  bodies  and  the  visible  parts  of  packages  may  contain  further  module  declarations.  The 
body  of  any  unit  declared  in  a module  specification  must  appear  in  the  corresponding  module 
body. 


7.2  Module  Specifications 


The  first  declarative  part  of  a module  specification  is  called  its  visible  part.  The  entities  declared  in 
the  visible  part  can  be  made  visible  to  other  program  units  by  means  of  a use  clause  (see  8 4)  or 
selected  components  (see  4. 1 .2).  A module  consisting  of  only  a module  specification  (i.e.,  without 
a module  body)  can  be  used  to  represent  a group  of  common  constants  or  variables,  or  a common 
pool  of  data  and  types. 

Example  of  a group  of  common  variables: 

package  PLOTTING_DATA  it 
PEN_UP  : BOOLEAN 

CONVERSION_FACTOR. 

X_OFFSET.  Y_OFFSET, 

X_MIN,  X_MAX, 

Y_MIN.  Y_MAX  . REAL. 

X_  VALUE.  Y_VALUE  : array  (1  . 500)  of  REAL; 
end  PL0TTING_DATA; 

Example  of  common  pool  of  data  and  types: 
package  W0RK_DATA  is 

type  DAY  is  (MON.  TUE.  WED,  THU.  FRI,  SAT,  SUN): 
type  DURATION  it  delta  001  range  0.0  . 24.0; 
type  TIMETABLE  is  array  (MON  . SUN)  of  DURATION; 

WORK_HOURS  : TIMETABLE: 

NORMAL-HOURS  : constant  TIME.TABLE  := 

(MON  THU  =>  8.25,  FRI  =>  7 0.  SAT  | SUN  =>  0 0) 

end  W0RK_DATA; 

The  visible  part  contains  all  the  information  that  another  program  unit  is  able  to  know  about  the 
module. 
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7.3  Module  Bodies 


The  visible  part  of  a module  may  contain  the  specification  of  subprograms  or  the  specification  of 
other  modules.  In  such  cases,  the  bodies  of  the  specified  units  must  appear  within  the  declarative 
part  of  the  module  body.  This  declarative  part  can  also  include  local  declarations  and  local  program 
units  needed  to  implement  the  visible  items. 

In  contrast  to  the  entities  declared  in  the  visible  part,  the  entities  declared  in  the  module  body  are 
not  accessible  outside  the  module.  As  a consequence,  a module  with  a module  body  can  be  used 
for  the  construction  of  a group  of  related  subprograms  (a  package  in  the  usual  sense),  where  the 
logical  operations  accessible  to  the  user  are  clearly  isolated  from  the  internal  entities. 

Example  of  a package : 

package  RATIONALN  UMBERS  la 
type  RATIONAL  la 
record 

NUMERATOR  : INTEGER; 

DENOMINATOR  : INTEGER  range  1 ..  INTEGER'LAST; 

end  record; 

function  '="  (X.Y  : RATIONAL)  return  BOOLEAN; 

function  *+'  (X.Y  ; RATIONAL)  return  RATIONAL; 

function  (X.Y  : RATIONAL)  return  RATIONAL; 

— Note:  hides  predefined  equality  for  RATIONAL  operands 

end; 

package  body  RATIONAL.NUMBERS  1a 

procedure  SAME_DENOMINATOR  (X,Y  : in  out  RATIONAL)  ia 
begin 

--  reduces  X and  Y to  the  same  denominator 

end; 

function  ’=*  (X.Y  : RATIONAL)  return  BOOLEAN  ia 
U.V  ; RATIONAL; 

begin 

U :=  X; 

V :=  Y; 

SAME_DENOMINATOR  (U.V); 
return  U. NUMERATOR  = V.NUMERATOR; 
end 

function  *+’  (X.Y  : RATIONAL)  return  RATIONAL  ia  ...  end  ' + 

function  (X.Y  : RATIONAL)  return  RATIONAL  ia  ...  end 

end  RATIONAL-NUMBERS; 

Notes: 

A variable  declared  in  a module  specification  or  body  retains  its  value  between  calls  to  sub- 
programs declared  in  the  visible  part.  Such  a variable  is  said  to  be  own  to  the  module. 
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7.4  Private  Type  Declarations 


The  structural  details  of  some  declared  types  may  be  irrelevant  to  their  logical  use  outside  a 
module.  This  may  be  accomplished  by  providing  a private  type  declaration. 

private_type .declaration  :: 

I restricted  I type  identifier  ie  privets : 

A private  type  declaration  can  only  appear  in  the  visible  part  of  a module  The  full  declaration  of  the 
private  type  must  appear  in  the  private  part  of  the  module  specification.  Such  types  are  called 
private  types. 

For  a private  type  (not  designated  as  restricted),  the  only  information  available  to  other  program 
units  is  that  given  in  the  visible  part  of  the  defining  module.  Hence,  the  name  of  the  type  and  the 
operations  specified  in  this  visible  part  are  available.  In  addition,  assignment  and  tho  predefined 
comparison  for  equality  or  inequality  are  available  (unless  a redefinition  of  equality  hides  the 
predefined  equality  and,  as  a consequence,  also  redefines  inequality). 

These  are  the  only  externally  available  operations  on  objects  of  a private  type.  External  units  can 
declare  objects  of  the  private  type  and  apply  available  operations  to  the  objects.  In  contrast,  exter- 
nal units  cannot  access  the  structural  details  of  objects  of  private  types  directly, 

A constant  value  of  a private  type  can  be  declared  in  the  visible  part  as  a deferred  constant.  Its 
actual  value  must  be  specified  in  the  private  part  by  redeclaring  the  constant  in  full. 

Assignment  and  the  predefined  comparison  for  equality  or  inequality  are  not  available  for  private 
type  declarations  containing  the  reserved  word  restricted.  Thus  if  a type  is  restricted,  the  only 
operations  available  on  objects  of  the  type  are  those  defined  by  the  subprograms  declared  in  the 
visible  part  A user  can  of  course  define  subprograms  calling  the  visible  operations. 

Example 

In  the  next  example  a private  type  KEY  is  defined  which  only  has  the  operations  of  assignment, 
comparison  for  equality  or  inequality,  comparison  for  "<",  and  an  operation  to  create  a value  of 
type  KEY. 

package  KEY_MANAGER  is 
type  KEY  is  private: 

NULL.KEY  : constant  KEY, 
procedure  GET. KEY  (K  : out  KEY): 
function  ”<"  (X,  Y : KEY)  return  BOOLEAN: 
private 

type  KEY  is  new  INTEGER  range  0 ..  INTEGER'LAST : 

NULL_KEY  : constent  KEY  :=  0; 
end: 


package  body  KEY_MANAGER  is 
LAST.KEY  : KEY  :=  0. 
procedure  GET_KEY(K  : out  KEY)  is 
bag  in 

LAST_KEY  :=  LAST_KEY  + 1; 

K :=  LAST.KEY. 
and  GET_KEY; 

function  '<"  IX.  Y : KEY)  ratum  BOOLEAN  la 

bagin 

ratum  INTEGER(X)  < INTEGER(Y); 

and 

and  KEY_MANAGER; 

Notes: 

The  expression  X<Y  within  the  body  of  the  function  "<"  would  be  a recursive  call  of  Hence, 
qualified  expressions  are  necessary  in  the  relation 

INTEGER(X)  < INTEGER(Y) 

Example: 

In  the  example  below,  an  external  subprogram  making  use  of  l_0_PACKAGE  may  obtain  a file 
name  by  calling  OPEN  and  later  use  it  in  calls  to  READ  and  WRITE.  Thus,  outside  the  module,  a file 
name  obtained  from  OPEN  ants  as  a kind  of  password.  Its  internal  properties  (e.g.,  containing  a 
numeric  value)  are  not  knowr  and  no  other  operations  (such  as  addition  or  comparison  of  internal 
names)  can  be  performed  01  a file  name.'. 

package  l_0_PACKAGE  I* 

restricted  type  FILE_NAME  is  private. 

procedure  OPEN  (F  : in  out  FILE_NAME); 
procedure  READ  (ITEM  : out  INTEGER;  F : In  FILE_NAME); 
procedure  WRITE  (ITEM  : in  INTEGER;  F : In  FILE_NAME); 
private 

type  FILE_NAME  is 
record 

INTERNAI — NAME  : INTEGER  :=  0; 
end  record; 
end  l_0_PACKAGE: 

package  body  l_0_PACKAGE  is 

LIMIT  ; constant  INTEGER  :=  200; 

type  FILE_DESCRIPTOR  is  record  ...  end  record; 

DIRECTORY  : array  (1  ..  LIMIT)  of  FILE_DESCRIPTOR; 

procedure  OPEN  (F  : in  out  FILE.NAME)  is  ...  end; 
procedure  READ  (ITEM  : out  INTEGER;  F : in  FILE_NAME)  Is  ...  end; 

procedure  WRITE  (ITEM  : in  INTEGER;  F : in  FILE_NAME)  is  ...  end. 

begin 

end  l_0_PACKAGE; 
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This  example  is  characteristic  of  any  case  where  complete  control  over  the  operation  of  a type  is 
desired  Such  packages  serve  a dual  purpose.  They  prevent  a user  from  making  use  of  the  internal 
structure  of  the  type.  They  also  implement  the  notion  of  an  encapsulated  data  type  where  the  only 
operations  over  the  type  are  those  given  in  the  module. 

I 

7.5  An  Illustrative  Table  Management  Package 


The  following  example  illustrates  the  use  of  package  modules  in  providing  high  level  procedures 
with  a simple  interface  to  the  user. 

The  problem  is  to  define  a table  management  package  for  inserting  and  retrieving  items.  The  items 
are  inserted  into  the  table  as  they  are  posted.  Each  posted  item  has  an  order  number.  The  items 
are  retrieved  according  to  their  order  number,  where  the  item  with  the  lowest  order  number  is 
retrieved  first. 

From  the  user  s point  of  view,  the  package  is  quite  simple  There  is  a type  called  ITEM  designating 
table  items,  a procedure  INSERT  for  posting  items,  and  a procedure  RETRIEVE  for  obtaining  the 
item  with  the  lowest  order  number.  There  is  a special  item  NULLITEM  that  is  returned  when  the 
table  is  empty,  and  an  exception  TABLE_FULL  that  may  be  raised  by  INSERT. 

A sketch  of  a module  implementing  such  a package  is  given  below.  Only  the  visible  part  of  the 
package  is  exposed  to  the  user. 

package  TABLE_MANAGER  is 

type  ITEM  is 
record 

ORDER_NUM  : INTEGER; 

ITEM_CODE  : INTEGER; 

ITEMJTYPE  : CHARACTER; 

QUANTITY  : INTEGER; 

and  record; 

NULLJTEM  ; constant  ITEM  := 

(ORDER_NUM  | ITEM_CODE  | QUANTITY  =>  0.  ITEMJTYPE  =>  " "); 

procedure  INSERT  (NEWJTEM  : in  ITEM); 
procedure  RETRIEVE  (FIRST JTEM  : out  ITEM); 

TABLE-FULL  : exception;  — may  be  raised  by  INSERT 

end: 

The  details  of  implementing  such  packages  can  be  quite  complex,  in  this  case  involving  a two  way 
linked  table  of  internal  items.  A local  housekeeping  procedure  EXCHANGE  is  used  to  move  an 
internal  item  between  the  busy  and  the  free  lists.  The  initial  table  linkages  are  established  by  the 
initialization  part.  The  package  body  need  not  be  shown  to  the  users  of  the  package. 
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package  body  TABLE_MANAGER  is 
SIZE  : constant  INTEGER  :=  2000; 
subtypa  INDEX  is  INTEGER  range  0 ..  SIZE; 

type  INTERNAL.ITEM  is 

record 

CONTENT  : ITEM; 

SUCC  : INDEX; 

PRED  : INDEX; 

end  record; 

TABLE  : array  (INDEX  FIRST  ..  INDEXLAST)  of  INTERNALITEM: 
FIRST_BUSY_ITEM  : INDEX  :=  0; 

FIRST_FREE_ITEM  : INDEX  :=  1; 

function  FREE_LIST_EMPTY  return  BOOLEAN  is  ...  end; 
function  BUSY_LIST_EMPTY  return  BOOLEAN  is  ...  end; 
procedure  EXCHANGE  (FROM  ; in  INDEX;  TO  ; in  INDEX)  is  ...  end; 

procedure  INSERT  (NEWJTEM  : in  ITEM)  is 

begin 

H FREE_LIST_EMPTY  then 
raise  TABLE_FULL; 

end  if; 

- remaining  code  for  INSERT 
end  INSERT; 

procedure  RETRIEVE  (FIRST_ITEM  : out  ITEM)  is  ...  end; 
begin 

--  initialization  of  the  table  linkages 
end  TABLE_MANAGER; 
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8.  Visibility  Rulst 
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This  chapter  describes  the  rules  defining  the  scope  of  declarations  and  the  rules  defining  which 
identifiers  are  visible  at  various  points  in  the  text  of  the  program  These  rules  are  stated  here  as 
applying  to  identifiers.  They  apply  equally  to  character  strings  used  as  function  designators  or 
enumeration  literals. 

A declaration  associates  an  identifier  with  a program  entitv,  such  as  a variable,  a type,  a sub 
program,  a formal  parameter,  a record  component,  etc.  The  region  of  text  over  which  a declaration 
has  an  effect  is  called  the  scope  of  a declaration. 

The  same  identifier  can  be  introduced  by  different  declarations  in  the  text  of  a program  and  thus  be 
associated  with  alternative  entities.  Hence  the  scopes  of  several  declarations  with  the  same  iden- 
tifier can  overlap. 

Overlapping  scopes  for  declarations  with  the  same  identifier  can  occur  because  of  overloading  of 
subprograms  or  of  enumeration  literals  (see  6.6  and  3.5.1).  Overlapping  scopes  can  also  occur 
because  of  nesting.  In  particular,  subprograms,  modules,  and  blocks  can  be  nested  within  each 
other;  similarly  these  units  can  contain  nested  record  type  definitions  or  nested  loop  statements. 

At  a given  point  of  text,  the  declaration  ~.f  an  entity  with  a certain  identifier  is  said  to  be  visible  if 
this  entity  is  an  acceptable  meaning  for  an  occurrence  of  the  identifier. 

For  overloaded  identifiers,  there  can  be  several  meanings  acceptable  at  a given  point,  and  the 
ambiguity  must  be  resolved  by  the  rules  of  overloading  (see  4.6  and  6.6).  For  other  identifiers  (the 
usual  case  and  the  case  considered  in  this  chapter)  there  can  be  at  most  one  acceptable  meaning. 
By  convention,  an  identifier  is  said  to  be  visible  if  its  declaration  is  visible.  The  visibility  rules  are 
the  rules  defining  which  identifiers  are  visible  at  various  points  of  the  text. 


8.1  Scope  of  Declarations 


Entities  can  be  introduced  by  declarations  in  various  ways.  An  entity  can  be  declared  in  a 
declarative  part  of  a block,  subprogram,  or  module.  An  enumeration  literal  is  declared  by  its  occur- 
rence in  an  enumeration  type  definition,  a loop  parameter  by  its  occurrence  in  an  iteration 
specification.  Finally,  entities  can  be  declared  as  record  components  or  as  formal  parameters  of 
subprograms,  entries,  and  generic  clauses. 

The  scopes  of  these  various  forms  of  declarations  and  the  scope  of  labels  are  defined  as  follows: 
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• The  scope  of  a declaration  given  in  the  declarative  part  of  a block,  subprogram  body,  or 
module  body  extends  from  (and  includes)  the  declaration  up  to  the  end  of  the  corresponding 
block,  subprogram,  or  module. 

• The  scope  of  a declaration  given  in  the  visible  or  private  part  of  a module  extends  from  (and 
includes)  the  declaration  to  the  end  of  the  module  specification.  It  also  extends  over  the  cor- 
responding module  body 

• The  scope  of  a declaration  given  in  the  visible  part  of  a module  also  extends  to  the  end  of  the 
scope  of  the  module  declaration  itself. 

• The  scope  of  an  enumeration  literal  is  the  scope  of  the  enumeration  type  declaration  (or 
definition)  itself. 

• The  scope  of  a record  component  extends  from  the  component  declaration  to  the  end  of  the 
scope  of  the  record  type  declaration  lor  definition)  itself. 

• The  scope  of  an  (unnamed)  enumeration  or  record  type  definition,  itself  given  within  a record 
type  definition,  extends  to  the  end  of  the  scope  of  the  enclosing  definition  (or  declaration). 

• The  scope  of  a formal  parameter  of  a subprogram,  entry,  or  generic  clause  extends  from  the 
parameter  declaration  to  the  end  of  the  scope  of  the  declaration  of  the  subprogram,  entry,  or 
generic  unit  itself. 

• The  scope  of  a loop  parameter  extends  to  the  end  of  the  corresponding  loop. 

• The  scope  of  a label  extends  from  the  first  occurrence  of  a label  to  the  end  of  the  innermost 
enclosing  compound  statement,  subprogram,  or  module.  The  first  occurrence  of  a label  can  be 
either  the  label  itself  or  its  use  in  a goto  statement. 


8.2  Visibility  of  Identifiers 


As  defined  in  the  previous  section,  the  scope  of  a declaration  always  extends  at  least  until  the  end 
of  the  language  construct  enclosing  the  declaration  (either  a block,  a subprogram,  an  accept  state- 
ment. a module,  a record  type  definition,  or  a loop  statement).  In  addition,  the  scope  extends  out- 
side the  enclosing  construct  tor  record  components,  formal  parameters,  and  items  declared  in  a 
module  visible  part. 

The  declaration  of  an  identifier  is  visible  at  a given  point  of  text  if  this  point  is  within  the  construct 
enclosing  its  declaration,  but  not  within  an  inner  construct  containing  another  declaration  with  the 
same  identifier.  An  entity  that  is  visible  in  this  manner  is  directly  visible,  that  is,  it  can  be  named 
simply  by  its  identifier. 


An  entity  declared  in  an  enclosing  construct  is  said  to  be  hidden  within  an  inner  construct  contain 
ing  another  declaration  with  the  same  identifier.  A subprogram  declaration  hides  another  sub- 
program only  if  their  specifications  are  equivalent  with  respect  to  the  rules  of  subprogram 
overloading  (see  6.6).  An  enumeration  literal  overloads  but  does  not  hide  another  enumeration 
literal.  Redeclaration  (as  opposed  to  overloading)  is  not  allowed  within  the  same  declaration  list  or 
component  list. 
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The  name  of  an  entity  declared  immediately  within  a subprogram  or  module  can  always  be  written 
as  a selected  component  within  this  unit,  whether  it  is  visible  or  hidden  The  name  of  the  unit 
(which  must  be  visible)  is  then  used  as  a prefix.  Thus,  component  selection  has  the  effect  of  open 
ing  the  visibility  for  the  occurrence  of  the  identifier  after  the  dot. 

Outside  its  construct  enclosing  its  declaration,  but  within  its  scope  a record  component,  a formal 
parameter,  or  an  item  of  a module  visible  pait  can  be  made  visible  as  follows: 

• A record  component  is  made  visible  by  a selected  component  whose  prefix  names  a record  of 
the  corresponding  type.  It  is  also  visible  as  a choice  in  an  aggregate  of  the  type 

• A formal  parameter  of  a subprogram,  entry,  or  generic  clause  is  visible  within  named 
parameter  associations  of  corresponding  subprogram  calls,  entry  calls,  or  generic  instantia 
tions. 

• An  entity  declared  within  a module  visible  part  is  made  visible  by  a selected  component 
whose  prefix  names  the  module.  It  may  also  be  made  directly  visible  via  a use  clause  (see 
8.4). 

Example. 

procedure  P is 
A BOOLEAN; 

B BOOLEAN; 

procedure  Q is 

C : BOOLEAN; 

B BOOLEAN  an  inner  redeclaration  of  B 

begin 

B A:  means  Q.B  P.A; 

C P B;  --  means  Q.C  P B; 

end 

begin 

A B means  P.A  :=  P.B; 

end 

Restrictions  on  redeclarations. 

An  identifier  used  (as  opposed  to  being  declared)  in  one  declaration  in  a declaration  (or  compo 
nent)  list  mcy  not  be  redeclared  in  subsequent  declarations  of  the  same  list  Thus  the  following  list 
of  declarations  is  illegal: 

M constant  INTEGER  2*N,  - using  N from  outer  scope 

N constant  INTEGER  : 10;  - illegal  redeclaration  of  N 

A variable  or  constant  of  an  enumeration  type  cannot  hide  an  enumeration  value  of  the  type.  The 
same  restriction  applies  to  a parameterless  function  returning  a result  of  an  enumeration  type 

Note  on  redeclaration-. 

An  inner  declaration  of  an  object  of  a given  type  hides  an  outer  declaration  of  a parameterless 
function  with  the  same  identifier  and  type,  and  vice  versa. 
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8.3  Restricted  Program  Units 


By  means  of  a visibility  restriction,  a program  unit  may  restrict  the  visibility  it  otherwise  has  of  out- 
er units. 

visibility_rest fiction  restricted  Ivisibilityjistl 

visibility — lisat  (t/n/f_name  |,  un/r_name|) 

In  all  cases,  the  predefined  identifiers  are  visible  within  the  restricted  program  unit.  If  no  visibility 
list  is  given,  no  other  identifiers  are  visible.  If  there  is  a visibility  list,  the  first  name  can  (but  need 
not)  be  the  name  of  a unit  enclosing  the  restricted  unit.  Entities  declared  within  the  enclosing  unit 
(if  given)  are  visible  as  usual.  Other  names,  if  given,  must  be  the  names  of  modules  that  are  outside 
the  given  enclosing  unit  or  the  restricted  unit  itself.  These  module  names  are  also  visible,  and  thus 
can  be  used  in  selected  components  and  use  clauses. 

The  outer  modules  could  be  library  modules.  A module  body,  whether  restricted  or  not,  always 
sees  the  visible  part  and  the  private  part,  if  any,  of  its  own  module  specification.  Within  a restricted 
program  unit,  a visibility  restriction  may  be  locally  superseded  by  another  visibility  restriction  given 
for  sn  inner  unit. 

Example. 

procedure  MAIN  ia 
U : BOOLEAN; 

package  A is 

LA  : BOOLEAN; 

end. 

package  B is 

LB  : BOOLEAN; 

end; 

restricted)  A) 
procedure  OUTSIDE  is 
V : BOOLEAN; 

reatricted(OUTSIDE.  INPUT_OUTPUT) 
procedure  DISPLAYIW  : BOOLEAN)  is 

begin 

- OUTSIDE,  V,  W,  DISPLAY,  and  INPUT_OUTPUT  are  visible  names. 

--  The  identifiers  of  the  visible  part  of  the  library  module  INPUT_OUTPUT 

- can  be  denoted  by  selected  components,  or  directly  if  a use  clause  is  given 

- for  the  module.  The  identifiers  B,  LB,  A,  LA,  U,  MAIN  are  not  visible 
end  DISPLAY; 

begin 

— A.  OUTSIDE,  V and  DISPLAY  are  visible  names 
— The  name  A.  LA  is  legal 

The  name  LA  can  be  made  directly  visible  by  a use  clause  for  A 
The  identifiers  B,  LB,  U,  MAIN  are  not  visible 
end  OUTSIDE; 

begin 

— U,  A,  B.  OUTSIDE  are  visible  names 
The  names  A LA  and  B.LB  are  legal 

The  name  LA  and  LB  can  be  made  directly  visible  by  a use  clause  for  A and  B 
end  MAIN; 
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Notes : 


If  the  visibility  list  includes  the  name  of  an  enclosing  unit,  the  names  of  modules  local  to  this  unit 
are  already  visible  and  hence  must  not  be  included  in  the  visibility  list. 


8.4  Use  Clauses 


If  the  name  of  a module  is  visible  at  a given  point  of  text,  the  identifiers  declared  within  the  visible 
part  of  the  module  can  be  denoted  by  selected  components.  In  addition,  these  identifiers  can  be 
made  directly  visible  by  means  of  a use  clause  at  the  start  of  a declarative  part. 

use_clause  ::=  usa  module  ^.n ame  |,  module  ~ name); 

The  names  appearing  in  the  use  clause  must  be  visible  module  names. 

In  order  to  define  the  set  of  identifiers  that  are  made  visible  by  use  clauses  at  a given  point  of  the 
text,  consider  the  set  of  module  names  appearing  in  the  use  clauses  of  the  current  and  all  enclos- 
ing units,  up  to  the  innermost  enclosing  restricted  unit. 

An  identifier  is  made  visible  by  a use  clause  if  it  is  defined  in  the  visible  part  of  one  and  only  one  of 
these  modules  and  if  it  is  not  visible  otherwise 

Several  overloaded  identifiers  (subprograms  or  enumeration  literals)  can  be  made  visible  by  use 
clauses  as  long  as  none  of  them  constitutes  a redefinition  of  an  otherwise  visible  identifier  or  of  an 
identifier  of  another  module  in  the  set. 

Thus  an  identifier  made  visible  by  a use  clause  can  never  hide  another  identifier  although  it  may 
overload  it.  If  an  identifier  appears  in  several  used  modules  or  is  otherwise  visible,  the  entity  cor- 
responding to  its  definition  in  one  of  the  modules  must  still  be  denoted  as  a selected  component. 
Renaming  and  subtype  declarations  may  help  avoiding  excessive  use  of  selected  components. 

Example  1 : 

procedure  R it 

use  TRAFFIC,  WATER_COLORS, 

— subtypes  used  to  resolve  the  conflicting  type  name  COLOR 
subtype  T_COLOR  is  TRAFFIC. COLOR; 
subtype  W_COLOR  is  WATER_COLORS.COLOR; 

SIGNAL  : T_COLOR; 

PAINT  : W_COLOR; 

begin 

SIGNAL  :=  GREEN;  - that  of  TRAFFIC 
PAINT  GREEN;  - that  of  WATER_COLORS 

end  R; 
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Example  2 . 


ckage  0 is 

T.  U.  V : BOOLEAN, 
d D; 


procadurs  P la 

packags  E ia 

B.  W.  V : INTEGER; 

and  E; 

procadufa  O ia 

T.  X : REAL. 


daciara 

uaa  D.  E. 


the  name  T means  Q.T,  not  D.T 
the  name  U means  D.U 
the  name  B means  E.B 
the  name  W means  E.W 
the  name  X means  Q.X 

the  name  V is  illegal  : must  be  written  either  D.V  or  E.V 


and  P; 


8.5  Renaming 


A renaming  declaration  associates  a local  name  with  an  entity. 

renaming_declaration 

identifier  : type_mark  renames  name; 

| identifier  : exception  renames  name; 

| subprogram_nature  designator  renames  (name  (designator; 

| module_nature  identifier  renames  name; 

The  identity  of  the  item  following  the  reserved  word  renames  is  established  when  the  renaming 
declaration  is  elaborated.  The  newly  declared  identifier  (or  designator)  takes  on  the  same  proper- 
ties (such  as  constancy,  parameter  types,  and  constraints,  etc.)  as  the  renamed  entity. 


8-6 


I 


A label  cannot  be  renamed.  An  entry  can  only  be  renamed  as  a procedure.  A subtype  can 
effectively  be  used  for  renaming  types  as  in 

subtype  ST  ia  S.T; 

Renaming  may  be  used  to  resolve  name  conflicts  (see  example  in  section  8.4),  to  achieve  partial 
evaluation  and  to  act  as  a shorthand. 

Examples'. 

procedure  TMR  renames  TABLELMANAGER. RETRIEVE; 
procedure  SORT  renames  QUICKS0RT2; 
task  LC  renames  LINK_C0NTR0LLER(6); 

declare 

L : PERSON  renames  LEFTMOST..PERSON; 

R : PERSON  renames  TO..BE_PROCESSED(NEXT); 
begin 

L.AGE  :=  L.AGE  + 1; 

RAGE  :=  RAGE  + 1; 

end; 

FULL  : exception  renames  TABLfc_MANAGER.TABLE_FULL; 

Notes'. 

Renaming  does  not  hide  the  old  name. 


8.6  Predefined  Environment 


All  predefined  identifiers,  for  example  built-in  types,  operators,  and  so  forth,  are  assumed  to  be 
defined  in  the  predefined  module  STANDARD  given  in  Appendix  C.  Other  installation  defined 
modules  may  be  included  in  the  default  environment  by  the  pragma 

pragma  ENVIRONMENT  (module  name  |,  modu/e  namej); 

All  identifiers  declared  in  the  visible  part  of  the  modules  of  the  default  environment  are  assumed 
declared  at  the  outermost  level  of  a program.  Visibility  restrictions  do  not  affect  the  visibility  of 
these  predefined  identifiers. 
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9.  Tasks 


Tasks  are  modules  that  may  operate  in  parallel.  Parallel  tasks  may  be  implemented  on  multicom- 
puters. multiprocessors,  or  with  interleaved  execution  on  a single  processor. 


9.1  Task  Declarations  and  Task  Bodies 


A task  declaration  is  a module  declaration  whose  module  nature  is  the  reserved  word  task.  A task 
consists  of  two  parts:  the  task  specification  and  the  task  body.  The  specification  can  specify  either 
a single  task  or  a family  of  similar  tasks  whose  individual  members  are  denoted  by  an  index  from  a 
discrete  range.  The  task  specification  (like  a package  specification)  comprises  a visible  part  and  an 
optional  private  part. 

The  visible  part  of  a task  specification  consists  of  declarations  specifying  the  interface  between  the 
task  and  other  external  units.  Entry  declarations  are  allowed  in  the  visible  part:  an  entry  is  used  for 
communication  between  tasks  in  mutual  exclusion.  Declarations  of  variables  and  modules  are  not 
allowed  in  the  visible  part. 

A task  body  specifies  the  execution  of  a task.  The  body  can  contain  accept  and  select  statements. 
It  can  also  contain  local  entry  declarations. 

Examples  of  task  declarations : 

teak  PRODUCER_CONSUMER  is 
entry  READ  (V  : out  ELEM); 
entry  WRITE  (E  : in  ELEM); 
end  PRODUCER_CONSUMER; 

task  MULTIPLEXER  is 
type  PRINTER  is  private; 
entry  OPEN  (P  : out  PRINTER); 
entry  CLOSE  (P  : in  PRINTER); 
entry  WRITE  (P  : in  PRINTER;  E : in  ELEM); 
entry  STOP.MULTIPLEXER; 
private 

type  PRINTER  is  new  INTEGER  range  1 ..  100 
end  MULTIPLEXER; 

task  LINK_CONTROLLER(INTEGER  range  1 ..  200)  is 
entry  SEND(P  : in  out  PACKET); 
entry  ACKNOWLEDGE; 
end  LI  N K_CONTRO  LLE  R ; 


9-1 


k 


tfc  TRACK_MANAGER  is 
type  TRACK  is  new  INTEGER  range  1..200; 
entry  START(U  : in  USER;  T ; in  TRACK); 
entry  TRANSFEROR ACK'FIRST  . TRACKLAST)  (I 
d TRACK_MANAGER; 


generic  task  KEY80ARD  is 

entry  READ  (C  : out  CHARACTER): 
entry  WRITE  |C  : in  CHARACTER); 
end  KEYBOARD; 

task  MY_KEYBOARD  is  new  KEYBOARD; 
task  USER;  — a task  with  no  visible  part 

Example  of  task  declaration  and  body 

tesk  PROTECTED_ARRAY  is 

— INDEX  and  ELEM  are  global  types 
entry  READ  (I  : in  INDEX;  V : out  ELEM); 
entry  WRITE  (I  : in  INDEX;  E : in  ELEM); 


in  ITEM); 


tesk  body  PROTECTED_ARRAY  is 

TABLE  erreydNDEX  FIRST  INDEXLAST)  of  ELEM  ;=  (INDEXFIRST  ..  INDEXLAST  = > 0); 


accept  READ  (I  : in  INDEX;  V ; out  ELEM)  do 
V :=  TABLE(I); 
end  READ: 

accept  WRITE  (I  : in  INDEX;  E ; in  ELEM)  do 
TABLE(I)  ;=  E; 
end  WRITE; 


end  loop; 

end  PROTECTED_ARRAY. 


9.2  Task  Hierarchy 


Tasks  may  be  declared  local  to  other  task  bodies,  packages,  subprograms,  and  blocks  but  not  in 
the  visible  part  of  another  task. 

The  elaboration  of  a task  declaration  creates  one  new  potentially  active  thread  of  control  (or,  in  the 
case  of  a family,  one  for  each  member  of  the  family).  This  thread  of  control  only  becomes  active 
when  an  initiate  statement  referring  to  the  task  is  executed.  Each  thread  of  control  has  a parent, 
which  is  the  thread  of  control  which  elaborated  the  corresponding  task  declaration  (and  is  not 
necessarily  the  thread  of  control  that  executed  the  initiate  statement).  A thread  of  control  can  only 
exist  if  its  parent  thread  of  control  is  active. 
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Each  elaboration  of  a task  declaration  can  only  create  one  thread  (i.e.  a task  cannot  be  multiply 
active)  and  so  the  thread  of  control  emanating  from  the  elaboration  of  that  task  declaration  may  be 
referred  to  as  the  task  without  ambiguity.  However,  if  a task  is  declared  in  a procedure,  each  call 
of  that  procedure  creates  a new  thread  of  control.  Normal  scope  rules  prevent  any  ambiguity. 


A procedure  or  entry  in  the  visible  part  of  a task  can  only  be  called  if  the  task  is  active.  If  the  task  is 
not  active,  the  TASKING_ERROR  exception  is  raised  in  the  task  issuing  the  call. 

Procedures  and  entries  in  the  visible  part  of  a family  of  tasks  apply  to  each  member  of  the  family 
and  are  denoted  by  using  the  member  name.  Thus,  outside  the  task  body  of  F,  the  procedure  P of 
the  l-th  member  of  the  family  F is  denoted  by 

F(I).P 

Types,  constants,  and  exceptions  apply  to  the  family  as  a whole  and  are  denoted  by  just  using  the 
family  name.  Thus,  the  type  T declared  in  the  visible  part  of  the  family  F is  denoted  by 

F.T 

Within  the  task  body,  if  selected  components  are  used  to  denote  items  local  to  the  task  body,  they 
must  only  mention  the  family  name. 

Notes: 

• The  main  program  is  implicitly  considered  to  be  a task  and  therefore  every  thread  of  control  is 
associated  with  a task. 

• A subprogram  can  be  used  reentrantly  by  several  threads  of  control. 

• The  implementation  of  task  creation,  although  described  in  dynamic  terms,  can  either  be 
dynamic  (storage  for  a task  is  allocated  when  the  task  is  initiated)  or  static  (storage  for  a task 
is  allocated  when  the  task  declaration  is  elaborated).  This  is  particularly  relevant  to  task 
families  which  can  be  viewed  in  a similar  manner  to  an  access  type;  the  index  range  gives  an 
upper  limit  on  the  number  of  active  tasks  in  the  family.  It  is  possible  to  influence  the 
implementation  of  a given  task  declaration  by  providing  an  appropriate  pragma  in  its  declara- 
tion: 

pragma  CREATION(STATIC); 
pragma  CREATION!  DYNAMIC); 


9.3  Task  Initiation 


The  execution  of  a task  body  is  initiated  by  an  initiate  statement. 

initiate_statement  ::= 

initiate  task_designator  |,  task_designatori; 

task_designator  task r_name  [(discrete_range)J 
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Execution  of  an  initiate  statement  allows  the  execution  of  the  designated  tasks  to  begin  in  parallel 
with  other  currently  active  tasks.  Tasks  of  a task  family  are  individually  initiated  by  following  the 
family  name  by  an  appropriate  index  or  collectively  initiated  by  following  the  family  name  by  a dis- 
crete range  denoting  all  or  part  of  the  family. 

On  completion  of  an  initiate  statement  the  designated  tasks  are  active.  Initiation  of  a terminated 
task  is  possible  and  results  in  a new  execution  of  the  task.  However,  an  attempt  to  initiate  a task 
that  is  already  active  raises  an  INITIATE_ERROR  exception  in  the  task  performing  the  initiate 
statement. 

Examples: 

initiate  MULTIPLEXER.  LINK_CONTROLLER(J),  MY_KEYBOARD; 
initiate  LINK.CONTROLLER  (3  ..  N); 

Notes: 

If  an  initiate  statement  refers  to  more  than  one  task,  the  tasks  are  made  active  simultaneously. 

A task  can  (but  need  not)  be  initiated  by  its  parent  (the  task  elaborating  its  task  declaration).  For 
example,  if  several  tasks  are  declared  in  the  body  of  a parent  task,  one  of  them  could  be  initiated  by 
the  parent  task,  or  by  another  of  the  declared  tasks,  or  by  an  outside  task  calling  a visible 
procedure  of  the  parent  task.  It  is  a consequence  of  the  rules  of  the  language  that,  in  any  case,  a 
task  cannot  be  initiated  unless  its  parent  task  is  active. 

The  parent  of  a task  need  not  be  the  task  lexically  enclosing  its  declaration.  For  example,  a task  T 
could  be  declared  in  a procedure  specified  in  the  visible  part  of  another  task.  The  parent  of  the  task 
T is  then  the  task  that  calls  the  procedure  and  this,  of  course,  need  not  be  the  enclosing  task. 


9.4  Normal  Termination  of  Taeks 


Normal  termination  of  a task  occurs  when  it  reaches  the  end  of  its  task  body  and  when  all  locally 
declared  tasks  (if  any)  have  terminated  their  execution.  More  generally,  any  subprogram,  module, 
or  block  containing  local  task  declarations  cannot  be  left  until  all  local  tasks  have  terminated  their 
execution. 


9.5  Entry  Declarations  and  Accept  Statements 


An  entry  declaration  is  similar  to  a subprogram  declaration.  For  other  tasks,  the  entry  appears  as  a 
subprogram  and  it  is  called  with  the  same  syntax  as  subprogram  calls.  An  entry  declaration  can 
also  specify  a family  of  identical  entries,  each  denoted  by  an  index  from  a discrete  range.  In  this 
case  every  call  must  be  subscripted  by  an  index. 

An  entry  can  be  declared  either  in  a task  specification  or  in  the  outermost  declarative  part  of  a task 
body,  but  not  in  any  other  declarative  part;  it  is  said  to  be  owned  by  the  corresponding  task 
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entry_declaration  ::= 

entry  identifier  l(discrete_range))  IformaLpartJ; 

accept_statement  ::= 

accept  enfry_name  (formal  parti  |do 
sequence_of_statements 
end  (identifier! | ; 

An  accept  statement  specifies  the  actions  to  be  performed,  if  any,  when  the  corresponding  entry  is 
called.  There  may  be  several  accept  statements  corresponding  to  one  entry. 

Execution  of  an  entry  call,  however,  may  be  delayed  until  the  task  owning  the  entry  reaches  an 
accept  statement  for  the  corresponding  entry.  There  are  two  possibilities: 

(a)  If  a calling  task  issues  an  entry  call  before  a corresponding  accept  statement  is  reached  by  the 
task  owning  the  entry,  the  execution  of  the  calling  task  is  suspended. 

lb)  If  a task  reaches  an  accept  statemjnt  prior  to  any  call  of  that  entry,  the  execution  of  the  task  is 
suspended  until  such  a call  occurs. 

When  an  entry  has  been  called  and  a corresponding  accept  statement  is  reachad,  the  sequence  of 
statements,  if  any,  of  the  accept  statement  is  executed  by  the  called  task  in  mutual  exclusion.  This 
interaction  is  called  a rendezvous.  Thereafter,  the  calling  task  and  the  task  owning  the  entry  can 
continue  their  execution  in  parallel. 

If  several  tasks  call  the  same  entry  before  a corresponding  accept  statement  is  reached,  the  calls 
are  queued;  there  is  only  one  queue  associated  with  each  entry.  Each  execution  of  an  accept 
statement  removes  one  call  from  the  queue.  The  calls  are  processed  in  order  of  arrival.  Each  task 
can  only  be  on  one  queue. 

Entries  may  be  overloaded  both  with  each  other  and  with  procedures  with  the  same  identifier.  An 
entry  may  be  renamed  as  a procedure. 

Restrictions  on  accept  statements: 

• A task  can  execute  accept  statements  only  for  its  own  entries.  Hence,  an  accept  statement 
cannot  appear  in  the  statements  of  a procedure  declared  in  the  visible  part  of  the  task,  nor  can 
it  appear  in  any  procedure  called  directly  or  indirectly  by  such  an  externally  visible  procedure 
or  by  an  internal  task.  An  accept  statement  can,  of  course,  occur  in  a subprogram  called  only 
by  the  task  owning  the  entry. 

• Initiation  of  a task  may  not  bs  performed  directly  or  indirectly  by  the  sequence  of  statements 
of  an  accept  statement. 

Examples  of  entry  declarations : 

entry  READIV  : out  ELEM); 

entry  TRANSFER  (TRACK' FIRST  ..  TRACK  LASTMI  : in  ITEM); 
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Examples  of  entry  calls : 


REAL XX) 

KAREAD(Y); 

LINK_C0NTR0ll.ER(3).  ACKNOWLEDGE; 

TRANSFER(TRACK_A)(J): 

Examples  of  accept  statements: 

•ccapt  READiV  : out  ELEM)  do 
V :=  LOCAL.EIEM; 

•n4  READ; 

accept  TRANSFERdld  : in  ITEM)  do 
and  TRANSFER; 

Notes: 

An  accept  statement  may  contain  other  accept  statements  (possibly  for  the  same  entry)  directly  or 
indirectly.  A task  may  call  its  own  entries  but  it  will,  of  course,  deadlock.  In  contrast,  a procedure 
declared  in  the  visible  part  of  a task  can  call  local  entries  of  the  task,  without  risk  of  automatic 
deadlock  when  the  procedure  is  called  by  other  tasks. 


9.6  Delay  Statements 


A delay  statement  suspends  the  task  which  executes  it  for  at  least  the  given  time  interval.  This 
interval  is  expressed  in  the  basic  time  unit  of  the  clock.  Time  values  may  be  expressed  in  terms  of 
the  predefined  constant  SECONDS,  which  gives  the  number  of  basic  time  units  in  one  second. 
The  type  of  the  time  interval  is  the  predefined  floating  point  type  TIME. 

delay_statement  ;;=  delay  simple_expression; 

Example: 

delay  3.0  * SECONDS; 

A delay  statement  can  occur  wherever  a statement  is  permitted. 


9.7  Select  Statement 

A select  statement  allows  a selective  wait  on  one  or  more  alternatives.  The  selection  may  depend 
on  conditions  associated  with  each  alternative  of  the  select  statement. 
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select_statement  ::= 


sal  act 

[when  condition  =>| 
select_alternative 
I or  [when  condition  =>| 
select_alternative( 

I else 

sequence_of_statements| 

end  seiect ; 

select-alternative 

accept_statement  [sequence_of_statements| 

| delay_statement  [sequence_of_statements[ 

A select  alternative  is  said  to  be  open  if  there  is  no  preceding  when  clause  or  if  the  corresponding 
condition  is  true.  It  is  said  to  be  closed  otherwise. 

Execution  of  a select  statement  proceeds  as  follows: 

(a)  All  conditions  are  first  evaluated  in  textual  order  to  determine  which  alternatives  are  open. 

(b)  An  open  alternative  starting  with  an  accept  statement  may  be  selected  if  a corresponding 
rendezvous  is  possible  (i.e.  when  a corresponding  entry  call  has  been  issued  by  another  task). 
When  such  an  alternative  is  selected,  the  corresponding  accept  statement  and  possible  sub- 
sequent statements  are  executed. 

(c)  An  open  alternative  starting  with  a delay  statement  will  be  selected  if  no  other  alternative  has 
been  selected  before  the  specified  time  interval  has  elapsed.  Any  subsequent  statements  of 
the  alternative  are  then  executed. 

(d)  If  no  alternative  can  be  immediately  selected,  and  there  is  an  else  part,  the  else  part  is 
executed.  If  there  is  no  else  part,  the  task  waits  until  an  open  alternative  can  be  selected. 

(e)  If  all  alternatives  are  closed  and  there  is  an  else  part,  the  else  part  is  executed.  If  there  is  no 
else  part,  the  exception  SELECT_ERROR  is  raised. 

In  general,  several  entries  of  a task  may  have  been  called  before  a select  statement  is  encountered. 
As  a result,  several  alternative  rendezvous  are  possible.  Similarly,  several  open  alternatives  may 
start  with  an  accept  statement  for  the  same  entry.  In  such  cases  one  of  these  alternatives  is 
selected  at  random.  If  several  open  alternatives  start  with  a delay  statement,  only  the  one  with  the 
shortest  time  interval  is  considered. 

A select  statement  cannot  contain  both  an  else  part  and  alternatives  starting  with  delay  state- 
ments. A select  statement  must  contain  at  least  one  alternative  commencing  with  an  accept 
statement  and  so  its  position  is  consequently  constrained  in  the  same  manner  as  the  accept  state- 
ment (see  9.5). 


Example. 


task  READER-WRITER  is 

procedure  READ  (V  : out  ELEM); 
•i* try  WRITEIE  : in  ELEM); 

and; 


task  body  READER. WRITER  is 
RESOURCE  : ELEM; 

READERS  : INTEGER  :=  0; 

entry  START; 
entry  STOP; 

procedure  READIV  : out  ELEM)  is 

--  READ  is  a procedure,  not  an  entry,  hence  concurrent  calls  of  READ  are  possible 
--  READ  synchronizes  such  calls  with  the  entry  calls  START  and  STOP 

begin 

START;  V ;=  RESOURCE;  STOP; 

end: 

begin 

accept  WRITEIE  : in  ELEM)  do 
RESOURCE  :=  E; 

end; 

loop 

select 

accept  START; 

READERS  ;=  READERS  + 1; 

or 

accept  STOP; 

READERS  :=  READERS  - 1; 
or  when  READERS  = 0 => 

accept  WRITEIE  : in  ELEM)  do 
RESOURCE  :=  E; 
end  WRITE; 
end  select; 
end  loop; 

end  READER-WRITER; 


9.8  Task  Priorities 


Each  task  has  an  associated  priority,  which  is  an  integer  value  of  the  implementation  defined  sub- 
type  PRIORITY,  defined  as: 

subtype  PRIORITY  is  INTEGER  range 

SYSTEM'MIN-PRIORITY  ..  SYSTEM’ MAX-PRIORITY; 


A lower  value  indicates  a lower  dugree  of  urgency.  The  main  program  of  a system  is  started  with 
an  implementation  defined  intermediate  priority.  Whenever  a task  is  initiated,  it  takes  the  priority 
of  its  initiator  at  that  time.  A task  can  set  its  own  priority  to  some  value  P by  a call  of  the 
predefined  procedure  SET  PRIORITY  thus: 

SET  PRIORITY(P); 

/Votes: 

There  may  be  several  tasks  that  are  ready  to  be  executed  by  the  system  processors.  In  choosing 
the  processes  to  be  executed,  processes  with  the  highest  priority  are  treated  first.  Processes  of  the 
same  priority  level  are  treated  on  a first  in.  first  out  basis  The  language  does  not  specify  when  a 
scheduling  decision  is  made.  For  example,  a round-robin  time  sliced  strategy  is  acceptable 

Priorities  should  only  be  used  to  indicate  degrees  of  urgency.  They  should  not  be  used  for  task  syn 
chronization. 


9.9  Taak  and  Entry  Attributes 


A task  T has  the  following  predefined  attributes: 

T ACTIVE  equal  to  TRUE  if  the  task  is  active  FAISE  otherwise 

T'PRIORITY  the  current  priority  of  the  task  T 

T'CLOCK  the  cumulative  processing  time  of  the  task  T 

The  real  time  system  clock  can  be  accessed  with  the  attribute  SYSTEM  CLOCK  The  cumulative 
processing  time  of  a task  is  initialized  to  zero  when  the  task  is  initiated.  The  attributes  T'Cl  OCK 
and  SYSTEM  CLOCK  are  of  type  TIME. 

When  a task  of  a family  F needs  to  reference  its  own  index,  for  example  to  pass  it  to  another  task,  it 
may  use  the  attribute  F'INDEX  for  that  purpose  This  attribute  cannot  be  used  in  the  visible  part  of 
the  family. 

For  an  entry  E,  the  attribide  E COUNT  gives  the  number  of  calls  to  the  entry  that  have  not  yet  been 
sorviced  This  attribute  can  only  be  used  in  the  body  of  the  task  owning  the  entry 


9.10  Abort  Statements 


Abnormal  termination  of  a task  is  caused  by  an  abort  statement 

abort  statement  : abort  task  .designator  l.task  designator  I : 

An  abort  statement  causes  the  unconditional  asynchronous  termination  of  the  tasks  mentioned  in 
the  list  of  task  designators  If  a task  is  not  active  (i.e.  not  yet  initiated  or  already  terminated)  there 
is  no  effect  Abnormal  termination  of  a task  causes  the  abnormal  termination  of  all  tasks  of  which 
it  is  the  direct  or  indirect  parent. 
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On  completion  of  the  abort  statement  the  designated  tasks  are  no  longer  active  If  a designated 
task  is  waiting  on  an  entry  queue  then  it  is  merely  removed  from  the  queue.  However  if  it  is 
already  engaged  in  a rendeivous,  the  other  task  receives  a TASKING_ERROR  exception 

Example. 

abort  TRACK_MANAGER.  LINK_CONTROLLER(  1 . 10); 

Notes. 

An  abort  statement  should  only  be  used  in  extremely  severe  situations  requiring  unconditional  ter- 
mination. In  less  extreme  cases  (where  the  task  to  be  terminated  can  be  given  the  possibility  of 
executing  some  cleanup  actions  before  termination),  the  exception  FAILURE  could  be  raised  for 
the  task  (see  1 1.5).  A task  may  abort  any  task  including  itself  and  its  parent. 


9.11  Signals  and  Semaphores 


Two  generic  tasks,  named  SIGNAL  and  SEMAPHORE,  are  predefined  in  the  language.  Their 
semantics  correspond  to  the  following  declarations: 

generic  task  SIGNAL  is 
entry  SEND; 
entry  WAIT; 

end  SIGNAL; 

task  body  SIGNAL  is 

RECEIVED  : BOOLEAN  FALSE; 

begin 

loop 

select 

accept  SEND; 

RECEIVED  :=  TRUE; 
or  when  RECEIVED  = > 
accept  WAIT; 

RECEIVED  :=  FALSE; 
end  select; 
end  loop; 

end  SIGNAL; 


generic  teak  SEMAPHORE  it 
entry  P; 
entry  V; 

end  SEMAPHORE; 

task  body  SEMAPHORE  it 
begin 
loop 

accept  P: 

accept  V; 
end  loop: 
end  SEMAPHORE; 

Example  of  use  of  a semaphore. 

tatk  SEMA  it  new  SEMAPHORE; 

initiate  SEMA; 

SEMAP; 

— mutual  exclusion 
SEMA.V; 

Although  the  task  declarations  above  are  given  in  the  language,  for  the  sake  of  semantic  descrip- 
tion their  being  predefined  authorizes  an  implementation  to  recognize  them  and  implement  them 
by  making  an  optimal  use  of  the  facilities  provided  by  the  machine  or  the  underlying  system. 


9.12  Example  of  Tasking 


The  following  example  defines  a buffering  task  to  smooth  variations  between  the  speed  of  output 
of  a producing  task  and  the  speed  of  input  of  some  consuming  task.  For  instance,  the  producing 
task  may  contain  the  statements 

loop 

— produce  the  next  character  CHAR 
BUFFER.WRITE(CHAR); 

exit  when  CHAR  = END_OF_TRANSMISSION; 
end  loop: 

and  the  consuming  task  may  contain  the  statements 

loop 

BUFFER. REAO(CHAR); 

consume  the  character  CHAR 
exit  when  CHAR  END_OF_TRANSMISSION; 

end  loop: 
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The  buffering  task  contains  an  internal  pool  of  characters  processed  in  a round- 
el 'T  ‘ndiC6S'  30  IN-,NDEX  the  space  for  the  next  input 

OUTJNDEX  denoting  the  space  for  the  next  output  character. 


task  BUFFER  is 

entry  READ  (C  : out  CHARACTER); 
entry  WRITE  (C  : in  CHARACTER); 

end; 


taefc  body  BUFFER  is 

POOLSIZE  : constant  INTEGER  ;=  100 

POOL  : array!  1 POOL_SIZE)  of  CHARACTER; 

COUNT  : INTEGER  range  0 ..  POOL.SIZE  :=  0 

INJNDEX,  OUT_INDEX  : INTEGER  range  1 . P00L_SIZE  •= 
begin 
loop 

•elect 

when  COUNT  ^ POOL..SIZE  => 

accept  WRITEIC  in  CHARACTER)  do 
POOL(INJNDEX)  : C; 

end; 

INJNDEX  INJNDEX  mod  POOL.SIZE  + 1 
COUNT  ;=  COUNT  + 1; 
or  when  COUNT  > 0 =“> 

accept  READIC  : out  CHARACTER)  do 
C :=  POOL(OUTJNDEX); 
end; 

OUTJNDEX  OUTJNDEX  mod  POOL_SIZE  + 1 
COUNT  :=  COUNT  - 1; 

end  setect; 
end  loop; 
end  BUFFER; 


robin  fashion.  The 
character  and  an 
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10.  Program  Structure  and  Compilation  laauaa 


This  chapter  describes  the  overall  structure  of  programs  and  the  facilities  for  separate  compilation 
of  their  parts.  A program  is  a collection  of  one  or  more  compilation  units.  These  can  be  subprogram 
bodies,  module  specifications,  or  module  bodies.  The  body  of  a unit  declared  within  another  unit 
can  be  separately  compiled  as  a subunit. 


10.1  Compilation  Unit* 

A program  can  be  compiled  as  a single  compilation  unit  or  it  can  be  submitted  to  the  compiler  as  a 
succession  of  compilation  units.  One  compilation  can  consist  of  several  such  units.  The  compila- 
tion units  of  a program  are  said  to  belong  to  a program  library 

compilation  ::=  |compilation_unit| 

compilation_unit  ::= 

|visibility_restriction||aaparata]  unit_body 

Each  compilation  unit  is  in  effect  a restricted  program  unit.  In  the  absence  of  an  explicit  visibility 
restriction,  an  empty  visibility  list  is  assumed.  The  visibility  rules  that  apply  to  compilation  units  fol- 
low from  those  that  apply  to  all  restricted  program  units  (see  8.3).  In  particular,  a separately  com- 
piled unit  that  makes  use  of  a separately  compiled  module  must  name  that  module  in  its  visibility 
list.  These  dependencies  between  units  have  an  influence  on  the  order  of  compilation  and  recom- 
pilation of  compilation  units. 

All  compilation  units  (that  are  not  subunits)  belonging  to  the  same  program  library  must  have  dif- 
ferent names. 

A compilation  unit  that  is  a subprogram  body  can  be  a main  program  in  the  usual  sense.  The 
means  by  which  main  programs  are  executed  are  not  within  the  language  definition. 

Example  1 : 

A compilation  unit  can  be  split  into  a number  of  compilation  units.  For  example,  consider  the  fol- 
lowing program. 


Example  la.  Single  compilation  unit'. 
procedure  PROCESSOR  it 


package  0 it 

LIMIT  : constant  INTEGER  :=  1000; 

TABLE  : array  (1  ..  LIMIT)  of  INTEGER; 
procedure  RESTART; 
end  D; 

peckage  body  D is 
procedure  RESTART  is 
begin 

for  I in  1 ..  LIMIT  loop 
TABLE(I)  :=  I; 

end  loop; 
end; 
begin 

RESTART; 
end  0; 

procedure  Q(X  : INTEGER)  is 
use  D; 
begin 

TABLE(X)  = TABLE(X)  + 1; 

end  Q; 
begin 

D. RESTART;  — reinitializes  TABLE 
end  PROCESSOR; 

The  following  three  compilation  units  define  a program  with  an  equivalent  effect  (the  broken  lines 
between  compilation  units  are  here  to  remind  the  reader  that  these  units  need  not  be  contiguous 
texts). 

Example  1b'.  Several  compilation  units: 

package  0 is 

LIMIT  : constant  INTEGER  :=  1000; 

TABLE  : array  (1  ..  LIMIT)  of  INTEGER; 
procedure  RESTART; 


package  body  D ia 

procedure  RESTART  is 
begin 


for  I in  1 ..  LIMIT  loop 
TABLE(I)  :=  I; 
end  loop; 
end; 
begin 

RESTART; 
end  D; 


restricted!  D) 

procedure  PROCESSOR  is 
procedure  Q(X  ; INTEGER)  is 
use  D; 
begin 

TAB  LEIX)  :=  TAB  LEIX)  + 1; 

end  Q; 
begin 

D. RESTART;  — reinitializes  TABLE 
end  PROCESSOR; 

Note  that  in  the  latter  version,  the  package  D is  (implicitly)  a fully  restricted  program  unit.  Hence,  it 
has  no  visibility  of  outer  identifiers  other  than  the  predefined  identifiers.  In  particular,  D does  not 
depend  on  any  identifier  declared  in  PROCESSOR  and  hence  can  be  extracted  from  PROCESSOR. 

The  procedure  PROCESSOR  is  also  a restricted  unit,  but  must  name  D in  its  visibility  list  in  order  to 
contain  a legal  use  clause  for  D. 

These  three  compilation  units  can  be  submitted  in  one  or  more  compilations.  For  example,  it  is 
possible  to  submit  the  package  specification  and  the  package  body  in  a single  compilation. 

Example  2\  A complete  program 

The  following  is  an  example  of  a complete  program  to  print  the  real  roots  of  a quadratic  equation. 
The  packages  MATH_LIB  and  TEXT_IO  (as  the  package  D in  the  previous  example)  may  be  used 
by  different  main  programs.  These  packages  are  assumed  to  be  already  present  in  the  program 
library. 


10-3 


restricted!  M AT H _LI B . TEXTJO) 
procedure  QUADRATIC_EQUATION  is 
uas  TEXT  JO; 

A.  B.  C.  D : FLOAT; 

begin 

GET(A);  GET(B);  GET(C); 

D :=  B**2  - 4.0*A*C; 
if  D < 0.0  then 

PUT(" IMAGINARY  ROOTS'); 

else 

declare 

use  MATH_LIB;  - note;  SORT  is  defined  in  MATHJ.IB 

begin 

PUTC'REAL  ROOTS  : "); 

PUTUB  - SQRT(D))/(2  0*A)); 

PUT((B  + SQRT(D))/(2.0*A)); 

PUT(NEWUNE); 

end; 
end  if: 

end  QUADRATIC_EQUATION; 

Notes: 

A module  that  is  a compilation  unit  (such  as  D or  MATH_LIB)  can  depend  on  other  separately 
compiled  modules. 

A visibility  restriction  need  only  mention  the  modules  that  are  actually  used  within  a compilation 
unit.  It  need  not  (and  should  not)  mention  other  modules  on  which  the  modules  of  the  visibility  list 
depend,  unless  these  other  modules  are  directly  used  in  the  compilation  unit.  For  example,  the 
implementation  of  the  package  )NPUT_OUTPUT  may  need  the  operations  provided  by  a more 
basic  package.  The  latter  should  not  appear  in  the  visibility  list  of  QUADRATIC_EQUATION,  since 
these  operations  are  not  directly  called  within  its  body. 

A compilation  unit  can  be  a generic  program  unit. 


10.2  Subunits  of  Compilation  Units 


The  body  of  a subprogram  or  module  declared  in  the  outermost  declarative  part  of  another  com- 
pilation unit  (or  subunit)  can  be  separately  compiled  and  is  then  said  to  be  a subunit.  Within  the 
subprogram  or  module  where  a subunit  is  declared,  its  body  is  represented  by  a body  stub  at  the 
place  where  the  body  would  otherwise  appear.  This  method  of  splitting  a program  permits 
hierarchical  program  development. 

body_stub  ::= 

subprogram_specification  is  separate; 

I module_nature  body  identifier  is  separata. 

A subunit  is  said  to  be  enclosed  by  the  compilation  unit  where  its  stub  is  given.  Transitively,  a sub- 
unit of  a subunit  of  a unit  is  also  said  to  be  enclosed  by  the  unit. 
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The  body  of  a subunit  must  have  a visibility  restriction,  itself  followed  by  the  reserved  word 
separate  (see  1 0. 1 ).  The  first  name  appearing  in  the  visibility  list  must  be  the  name  of  an  enclosing 
compilation  unit.  The  name  of  a subunit  is  local  to  its  immediately  enclosing  unit.  In  consequence 
several  subunits  of  the  same  name  can  exist  within  a program  library. 

Example  3a: 

The  procedure  TOP  is  first  written  as  a compilation  unit  without  subunits. 

procedure  TOP  is 

type  REAL  is  digits  10; 

R,  S : REAL; 

package  D is 

PI  : constant  REAL:=  3.14159,26536; 
function  F (X:  REAL)  return  REAL; 

procedure  G (Y,  Z:  REAL); 
end  0; 

package  body  D is 

— some  local  declarations  of  D followed  by 
function  F(X  : REAL)  return  REAL  is 
begin 

— sequence  of  statements  of  F 

end  F; 

restricted(TOP,  INPUT_OUTPUT) 
procedure  G(Y,  Z : REAL)  is 

begin 

--  sequence  of  statements  of  G 

end  G; 
end  D; 

procedure  Q(U  ; in  out  REAL)  is 
use  D; 

begin 

U :=  F(U); 

end  Q; 

begin  --  TOP 

Q(R); 

D.G(R,  S); 
end  TOP; 


10-5 


w 


Example  3b\ 


The  package  body  D and  the  body  of  the  subprogram  Q can  be  made  into  separate  subunits  of  TOP 
as  follows: 

procedure  TOP  is 

type  REAL  is  digits  10; 

R.  S : REAL; 

package  0 is 

PI  : constant  REAL  ;=  3.14159_26536; 
function  F (X  : REAL)  return  REAL; 
procedure  G (Y.  Z : REAL); 
end  D; 

package  body  D is  separate;  - stub  of  D 

procedure  Q(U  : in  out  REAL)  is  separate;  — stub  of  Q 
begin  - TOP 

Q(R>: 

D.G(R,  S); 
end  TOP; 


restricted(TOP) 

separate  procedure  Q(U  : in  out  REAL)  is 
use  D; 
begin 

U :=  F(U); 

end  Q; 


restricted  (TOP) 

separate  package  body  0 is 

— some  local  declarations  of  D followed  by 

function  F(X  ; REAL)  return  REAL  is 
begin 

- sequence  of  statements  of  F 

end  F; 


procedure  G(Y,  Z : REAL)  is  separate;  --  stub  of  G 
end  D; 
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r«atrict«d(TOP  INPUT_OUTPUT) 
separate  procedure  G(Y.  Z REAL)  ia 
begin 

- sequence  of  statements  of  G 

end  G: 

In  the  above  example,  Q and  D are  subunits  of  TOP  (TOP  encloses  0 and  D);  G is  a subunit  of  D (D 
encloses  G and  similarly  TOP  encloses  G).  The  visibility  list  of  G must  mention  TOP  since  G acces 
ses  the  type  REAL  (mentioning  D instead  of  TOP  would  not  be  enough). 

Note  that  the  visibility  lists  in  the  split  version  are  established  in  such  a mariner  that  the  same  iden 
tifiers  are  visible  at  all  program  points  as  in  the  initial  version.  For  example,  the  variables  R and  S 
declared  in  TOP.  the  constant  PI  declared  in  the  visible  part  of  D and  the  other  entities  declared  in 
the  package  body  D are  all  visible  within  the  sequence  of  statements  of  the  subunit  G 


10.3  Order  of  Compilation 


The  visibility  rules  that  apply  to  compilation  units  (whether  subunits  or  not)  are  the  usual  rules  that 
apply  to  all  restricted  program  units. 

The  rules  defining  the  order  in  which  units  can  be  compiled  are  direct  consequences  of  the  visibility 
rules.  A unit  must  be  compiled  after  all  compilation  units  whose  names  appear  in  its  visibility  list  or 
in  the  visibility  list  of  any  textually  nested  subprogram  or  module.  A module  body  must  be  com 
piled  after  the  corresponding  module  specification.  The  subunits  of  a unit  must  be  compiled  after 
the  unit. 

Consistent  with  the  partial  ordering  defined  above,  tiie  compilation  units  of  a program  can  be  com 
piled  in  any  order. 

In  the  previous  examples: 

(a)  The  package  body  D must  be  compiled  after  the  corresponding  package  specification  (exam 
pie  1b). 

(b)  The  specification  of  the  package  D must  be  compiled  before  the  procedure  PROCESSOR.  On 
the  other  hand,  the  procedure  PROCESSOR  can  be  compiled  either  before  or  after  the 
package  body  D. 

(c)  The  procedure  QUADRATIC-EQUATION  (example  2)  must  be  compiled  after  the  library 
modules  MATH_LIB  and  INPUT-OUTPUT  that  appear  in  its  visibility  list.  Similarly  (example 
3a)  the  procedure  TOP  must  be  compiled  after  the  library  module  INPUT-OUTPUT  that 
appears  in  the  visibility  list  of  the  nested  procedure  G.  On  the  other  hand,  in  example  3b 
INPUT-OUTPUT  could  be  compiled  after  TOP. 

(d)  The  subunits  Q and  D (example  3b)  must  be  compiled  after  the  compilation  unit  TOP.  Similar 
ly  the  subunit  G must  be  compiled  after  the  enclosing  unit  D.  Note  also  that  the  library  module 
INPUT-OUTPUT  must  be  compiled  before  G 
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Similar  rules  apply  for  recompilations.  Any  change  in  a given  compilation  unit  can  only  affect  its 
subunits  and  other  compilation  units  mentioning  the  unit  in  their  visibility  lists.  Hence  the  poten 
tially  affected  units  need  to  be  recompiled.  An  implementation  may  be  able  to  reduce  the  recom 
pilation  costs  if  it  can  deduce  that  some  of  the  potentially  affected  units  are  not  actually  affected 
by  the  change. 

Note  that  the  subunits  of  a unit  can  always  be  recompiled  without  affecting  the  unit  itself.  Similar- 
ly. changes  in  a module  body  do  not  affect  other  (non-nested)  units,  since  these  units  only  have 
access  to  the  visible  part  of  the  module.  Hence  to  minimize  recompilations,  it  is  advantageous  to 
compile  the  module  body  and  the  module  specification  (the  visible  part)  in  different  compilations. 


1 0.4  Program  Library 


Compilers  must  preserve  the  same  degree  of  type  safety  for  a program  consisting  of  several  com- 
pilation units  and  subunits,  as  for  a program  submitted  as  a single  compilation  unit.  Consequently 
a library  file  containing  information  on  the  compilation  units  of  the  program  library  must  be  main- 
tained by  the  compiler.  This  information  may  include  symbol  tables  and  other  information  pertain- 
ing to  the  order  of  previous  compilations. 

A normal  submission  to  the  compiler  consists  of  the  compilation  unit(s)  and  the  library  file.  The  lat- 
ter is  used  for  checks  and  is  updated  as  a consequence  of  the  current  compilation. 

There  should  be  compiler  commands  for  creating  the  program  library  of  a given  program  or  of  a 
given  family  of  programs.  These  commands  may  permit  the  reuse  of  units  of  other  program 
libraries.  Finally,  there  should  be  commands  for  interrogating  the  status  of  the  units  of  a program 
library.  The  form  of  these  commands  is  not  specified  by  the  language  definition. 


10.5  Elaboration  of  Compilation  Units 


Before  the  execution  of  a main  program,  all  library  modules  that  are  not  subunits  and  that  are  used 
by  the  main  program  are  elaborated.  These  modules  are  units  mentioned  in  the  visibility  lists  of  the 
main  program  and  of  its  subunits,  and  transitively  in  the  visibility  lists  of  these  library  modules 
themselves. 

The  elaboration  of  these  modules  is  performed  consistently  with  the  partial  ordering  defined  by  the 
visibility  lists  (see  10.3). 
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1 0.6  Program  Optimization 


A static  expression  can  be  evaluated  by  the  compiler.  In  consequence,  if  a static  expression  is 
required  and  the  actual  expression  involves  a variable,  or  if  an  exception  arises  in  the  evaluation  of 
the  expression,  then  the  program  is  in  error.  On  the  other  hand,  a compiler  may  be  able  to  optimize 
a program  by  evaluating  expressions  which  are  not  required  to  be  static.  If  the  evaluation  raises  an 
exception,  then  the  code  in  that  path  in  the  program  can  be  replaced  by  code  to  raise  the  excep 
tion.  Under  such  circumstances,  the  compiler  may  warn  the  programmer  of  a potential  error. 

Optimization  of  the  elaboration  of  declarations  and  the  execution  of  statements  may  be  performed 
by  compilers.  If  a subprogram  is  compiled  by  an  in-line  substitution  of  the  body,  then  expressions 
within  the  body  may  be  capable  of  further  optimization  as  above. 

A compiler  may  find  that  some  statements  or  subprograms  cannot  be  executed,  in  which  case  the 
corresponding  code  can  be  omitted.  If  non-static  expressions  within  such  code  would  generate  an 
exception,  then  the  program  is  not  in  error.  These  rules  permit  the  effect  of  conditional  compilation 
within  the  language 


11.  Exceptions 


This  chapter  defines  the  facilities  for  dealing  with  errors  or  other  exceptional  situations  that  arise 
during  program  execution.  An  exception  is  an  event  that  causes  suspension  of  normal  program 
execution.  Bringing  an  exception  to  attention  is  called  raising  the  exception.  To  execute  some 
actions,  in  response  to  the  occurrence  of  an  exception,  is  called  handling  the  exception 

The  units  whose  execution  can  be  prematurely  terminated  by  an  exception  are  blocks,  sub- 
programs, and  modules.  Exceptions  are  introduced  by  exception  declarations.  Exceptions  can  be 
raised  explicitly  by  raise  statements,  or  they  can  be  propagated  by  subprograms  blocks  or 
language  defined  operations  that  raise  the  exceptions.  When  an  exception  occurs,  control  can  be 
passed  to  a user-provided  exception  handler. 


11.1  Exception  Declaration* 


An  exception  declaration  defines  one  or  several  exceptions  whose  names  can  appear  in  raise  state- 
ments and  in  exception  handlers  within  the  scope  of  the  declaration. 

exception_declaration  ::=  identifierjist  : exception; 

The  identity  of  the  exception  introduced  by  an  exception  declaration  is  established  at  compilation 
time  (exceptions  can  be  viewed  as  constants  of  some  predefined  enumeration  type  initialized  with 
static  expressions).  Hence  an  exception  declaration  introduces  only  one  exception  even  if  it  is 
declared  in  a recursive  procedure. 

Examples  of  user-defined  exception  declarations'. 

SINGULAR  : exception; 

END_OF_FILE  . exception; 


STACK_OVERFLOW,  STACK_UNDERFLOW  : exception; 


The  following  exceptions  are  predefined  in  the  language: 


ACCESS-ERROR 

ASSERT-ERROR 

DISCRIMINANT-ERROR 

DIVIDE-ERROR 

FAILURE 

INDEX-ERROR 

INITIATE-ERROR 


When  an  access  variable  has  the  value  null  and  an  attempt 
is  made  to  read  or  to  update  the  designated  dynamic 
object  (see  3.8). 

When  violating  an  assertion  (see  5.9). 

When  attempting  to  access  a component  of  a variant  part 
not  prescribed  by  the  record's  discriminant  (see  4.1.2). 

When  dividing  a number  by  zero  (see  4.5.5,  4.5.6). 

For  general  use  within  procedures  and  tasks.  This  is  the 
only  exception  that  can  be  raised  by  a task  for  another  task 
(see  11.3,  11. 5). 

When  an  index  value  is  outside  the  range  specified  for  the 
array  (see  4.1.1). 

When  attempting  to  initiate  a task  that  is  already  active 
(see  9.3). 


NO_VAlUE_ERROR 

OVERFLOW 

OVERLAP-ERROR 

RANGE-ERROR 

SELECT-ERROR 

STORAGE-OVERFLOW 

TASKING-ERROR 

UNDERFLOW 


When  accessing  the  value  of  an  uninitialized  variable  or 
returning  from  a function  without  a value  (see  6.5). 

When  an  arithmetic  operation  fails  by  attempting  to 
produce  a value  which  is  too  large  to  be  handled  by  the 
implementation  (see  4.5). 

When  attempting  to  assign  overlapping  slices  (see  5.1.1). 

When  exceeding  the  declared  range  of  a variable  or  type 
(see  4.5). 

When  all  alternatives  of  a select  statement  without  else 
part  are  closed  (see  9.7). 

When  the  dynamic  storage  allocated  to  a task  is  exceeded, 
or  during  the  execution  of  an  allocator,  if  the  available 
space  for  the  collection  of  dynamic  objects  is  exhausted 
(see  13.2). 

When  exceptions  arise  during  intertask  communication 
(see  9.2,  11.4). 

When  a floating  point  operation  fails  by  attempting  to 
produce  a value  which  is  too  small  to  be  handled  by  the 
implementation  (see  4.5.5). 


11.2  Exception  Handlers 


i 


The  processing  of  one  or  more  exceptions  is  specified  by  an  exception  handler.  A handler  may 
appear  at  the  end  of  a unit  which  must  be  a block,  subprogram  body,  or  module  body.  The  word 
unit  will  have  this  meaning  in  this  section. 

exception_handler  ::= 

when  exception_choice  f|  exception_choice|  => 
sequence_of_statements 

exception_choice  ::=  exception_r\ame  | others 

Each  handler  handles  the  named  exceptions  when  they  are  raised  in  the  given  unit.  An  alternative 
containing  the  choice  others  applies  to  all  exceptions  not  listed  in  other  alternatives,  including 
exceptions  whose  names  are  not  visible  within  the  current  unit. 

When  an  exception  is  raised  within  a unit,  either  during  elaboration  of  its  local  declarations,  or  dur- 
ing the  execution  of  its  sequence  of  statements,  the  execution  of  the  corresponding  handler 
replaces  the  execution  of  the  remainder  of  the  unit:  the  actions  following  the  point  where  the 
exception  is  raised  are  skipped,  and  the  execution  of  the  handler  terminates  the  execution  of  the 
unit.  If  no  handler  is  provided  for  the  exception,  the  unit  is  terminated  and  the  exception  is 
propagated  according  to  the  rules  stated  in  section  11.3.1. 

Since  a handler  acts  as  a substitute  for  the  corresponding  unit,  the  handler  has,  in  genera!,  the 
same  capabilities  as  the  unit  it  replaces.  For  example,  a handler  within  a function  has  access  to  its 
parameters  and  may  issue  a return  statement  on  behalf  of  the  function.  However,  since  an  excep- 
tion may  be  raised  during  the  elaboration  of  the  declarations  local  to  the  unit  considered,  it  cannot 
be  assumed  within  a handler  that  all  declarations  have  been  elaborated. 

Example : 

begin 

--  sequence  of  statements 

exception 

when  SINGULAR  | OVERFLOW  => 

PUT("  MATRIX  IS  SINGULAR  "); 
when  others  => 

PUTI’  FATAL  ERROR  "); 
raise  FAILURE; 

end: 
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11.3  Rai*«  Statements 


An  exception  can  be  explicitly  raised  by  a raise  statement. 
raise_statement  ::  raise  |excepf/o/»_name|; 

A raise  statement  raises  the  named  exception.  A task  can  raise  the  predefined  exception  FAILURE 
in  another  task  (say  T)  by  giving  T.FAILURE  as  exception  name.  A raise  statement  of  the  form 

raise; 


can  only  appear  in  a handler.  It  reraises  the  same  exception  which  caused  transfer  to  the  handler. 
Examples: 


raise. 

raise  SINGULAR; 

raise  MULTIPLEXER. FAILURE; 

raise  LIN  K_CONTROLLFR(5).  FAILURE; 

raise  OVERFLOW;  - explicitly  raising  a predefined  exception 


11.3.1  Dynamic  Association  of  Handiers  with  Exceptions 


When  an  exception  is  raised,  normal  program  execution  is  suspended  and  one  of  the  followina 

events  takes  place. 

(a)  If  a block  does  not  contain  a local  handler  for  the  exception,  execution  of  the  block  is  ter- 
minated and  the  same  exception  is  reraised  in  the  enclosing  sequence  of  statements.  Similar- 
ly, if  a subprogram  does  not  contain  a local  handler,  its  execution  is  terminated  and  the  excep- 
tion is  reraised  at  the  point  of  call  of  the  subprogram.  In  both  cases  the  exception  is  said  to  be 
propagated.  The  predefined  exceptions  are  exceptions  that  can  be  propagated  by  the 
language  defined  constructs. 

(b)  If  a task  does  not  contain  a local  handler  for  the  exception  the  task  is  terminated  but  the 
exception  is  not  propagated. 

(c)  If  a local  handler  has  been  provided,  execution  of  the  handler  replaces  execution  of  the 
remainder  of  the  current  unit.  A further  exception  raised  in  the  sequence  of  statements  of  the 
handler  causes  termination  of  the  current  unit,  and  the  exception  is  propagated  if  the  current 
unit  is  a block  or  subprogram  as  in  case  (a). 


i 


■ 
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Example. 


Wk 


procedure  P it 

ERROR  : nctption: 
procedure  R 

procedure  Q it 
begin 
R 

exception 

when  ERROR  => 


exception  possibility(2) 


handler  E2 


procedure  R it 
begin 

end  R: 


exception 

when  ERROR  => 


end  P; 


— exception  possibility) 3 ) 


— exception  possibility!  1 ) 


handler  El 


The  following  cases  can  arise: 

( 1 ) If  the  exception  ERROR  is  raised  in  the  statement  list  of  the  outer  procedure  P,  the  handler  E 1 
provided  within  P is  used  to  complete  the  execution  of  P 

(2)  If  the  exception  ERROR  is  raised  in  the  statement  list  of  Q,  the  handler  E2  provided  within  0 is 
used  to  complete  the  execution  of  Q.  Control  will  be  returned  to  the  point  of  call  of  Q upon 
completion  of  the  handler. 

(3)  If  the  exception  ERROR  is  raised  in  the  body  of  R,  called  by  Q,  the  execution  of  R is  ter- 
minated and  the  same  exception  is  raised  in  the  body  of  Q.  The  handler  E2  is  then  used  to 
complete  the  execution  of  Q,  as  in  case  (2). 

The  third  case  results  in  a dynamic  binding,  since  the  exception  raised  in  R results  in  passing  con- 
trol to  a local  handler  in  Q that  is  not  visible  from  R.  Note  also  that  if  a handler  were  provided 
within  R for  the  choice  others,  case  3 would  cause  execution  of  this  alternative,  rather  than  direct 
termination  of  R. 

Lastly,  if  ERROR  had  been  declared  inside  R,  rather  than  in  P,  the  handlers  El  and  E2  could  not 
provide  an  explicit  handler  for  ERROR  since  this  identifier  would  not  be  visible  within  the  bodies  of 
P and  Q.  In  case  3,  the  exception  could  however  be  handled  in  Q by  providing  a handler  for  the 
choice  others. 
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Example. 


function  FACTORIAL  (N  INTEGER)  return  FLOAT  is 


fc- « — 

Df9»n 

if  N = 1 then 
return  1 0; 

etee 

return  FLOAT(N)  * FACTORIALS- 1); 

end  if: 
exception 

when  OVERFLOW  =>  return  FLOAT  LARGE: 
end  FACTORIAL; 

If  the  multiplication  operation  causes  overflow,  then  FLOAT  LARGE  is  returned  by  the  handler.  This 
value  will  cause  further  overflow  exceptions  in  the  remaining  activations  of  the  function,  so  that  for 
large  values  of  N the  function  will  ultimately  return  the  value  FLOAT'LARGE. 

Example. 

declare 

ELABORATION_DONE  : BOOLEAN  :=  FALSE; 

L : array  (1  ..  10_000*l)  of  INTEGER; 

1— 

E LABOR ATION_DONE  :=  TRUE; 

— further  statements  of  the  block 

exception 

when  STORAGE_OVERFLOW  => 

- must  not  refer  to  L without  checking  ELABORATION_DONE 

end: 

This  example  illustrates  the  kind  of  precautions  that  have  to  be  taken  if  an  exception  can  occur  dur- 
ing the  elaboration  of  declarations. 


l 


11.4  Exceptions  Raised  during  Tasking 


An  exception  can  be  propagated  to  a task  communicating,  or  attempting  to  communicate,  with 
another  task. 

On  any  attempt  to  call  an  entry  or  a subprogram  of  an  inactive  task,  the  TASKING_ERROR  excep- 
tion is  raised  in  the  invoking  task.  Note  that  this  also  applies  to  entry  calls  to  an  active  task  if  the 
task  terminates  before  accepting  these  calls. 

A rendezvous  can  be  terminated  abnormally  in  three  cases. 

(a)  When  an  exception  is  raised  inside  an  accept  statement  and  not  handled  locally.  In  this  case, 
the  exception  Is  propagated  both  in  the  unit  containing  the  accept  statement  and  in  the  calling 
task  at  the  point  of  the  entry  call.  (A  different  treatment  is  employed  for  the  exception 
FAILURE  as  explained  in  section  11.6  below.) 

(b)  When  the  unit  containing  the  accept  statement  is  terminated  abnormally  (e.g.  as  the  result  of 
an  abort  statement).  In  this  case,  the  TASKING_ERROR  exception  is  raised  in  the  calling  task 
at  the  point  of  the  entry  call. 
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(c)  When  the  unit  issuing  the  entry  call  is  terminated  abnormally.  In  this  case  the  rendezvous  ter 
minates  abnormally  and  the  TASKING_ERROR  exception  is  raised  within  the  called  task,  in 
the  unit  containing  the  accept  statement. 

A task  calling  a procedure  of  nother  task  receives  a TASKING.  ERROR  exception  if  the  called  task 
terminates  before  the  end  of  the  procedure  execution. 

11.5  Raising  an  Excaption  in  Another  Task 

A task  can  raise  the  predefined  exception  FAILURE  in  another  task  (say  T)  by  a raise  statement  of 
the  form: 

raisa  T. FAILURE; 

The  execution  of  this  statement  has  no  direct  effect  on  the  task  issuing  the  statement  (unless,  of 
course,  it  raises  FAILURE  for  itself). 

If  the  task  receiving  the  FAILURE  exception  is  currently  executing,  or  if  it  is  suspended  by  an 
accept  or  select  statement,  the  effect  is  to  raise  the  exception  at  the  point  of  the  current  statement. 
If  the  task  is  suspended  on  a delay  statement,  the  corresponding  wait  is  cancelled  and  the  excep- 
tion is  raised  at  the  point  of  the  delay  statement.  If  the  task  has  issued  an  entry  call,  the  exception 
is  raised  at  the  point  of  the  call  and  two  cases  are  possible  for  the  called  task: 

(a)  If  the  entry  call  has  not  yet  been  accepted,  the  call  is  cancelled  and  the  called  task  is  unaf 
fected. 

(b)  If  an  accept  statement  for  this  entry  is  in  execution,  the  rendezvous  is  abnormally  terminated 
and  the  TASKING_ERROR  exception  is  raised,  as  in  section  1 1 4(c). 

If  a FAILURE  exception  is  received  by  a suspended  task,  execution  of  the  task  is  scheduled 
according  to  the  priority  rules  (see  9.8)  in  order  to  allow  handling  of  the  exception.  If  the  exception 
FAILURE  is  received  within  an  accept  statement  and  not  handled  locally,  the  rendezvous  is  ter- 
minated and  the  exception  TASKING_ERROR  is  raised  in  the  calling  task  at  the  point  of  the  entry 
call. 

The  predefined  exception  FAILURE  is  the  only  exception  that  can  be  explicitly  raised  in  another 
task.  It  supersedes  all  other  exceptions  not  yet  handled  or  received  before  FAILURE  is  handled  A 
unit  can  con.din  a handler  for  the  exception  FAILURE  as  for  any  other  exception. 

11.8  Suppressing  Exceptions 

The  detection  of  exception  conditions  may  be  suppressed  within  a unit  by  a pragma  of  the  form: 

pragma  SUPPRESSlexcepf/on.name  I,  excepr/on_name|) 

This  pragma  indicates  that  no  run  time  checks  need  be  provided  to  ensure  that  the  named  excep 
tions  do  not  arise.  The  occurrence  of  such  a pragma  within  a given  unit  does  not  guarantee  that 
the  named  exceptions  will  not  arise  since  the  pragma  is  merely  a recommendation  to  the  compiler 
and  since  the  exceptions  may  be  propagated  by  called  units.  Should  an  exception  situation  occur 
when  the  corresponding  run  time  checks  are  omitted,  the  program  would  be  erroneous  and  the 
results  unpredictable. 
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12.  Generic  Program  Units 


Subprograms  and  modules  can  be  generic.  Generic  programs  units  may  be  thought  of  as  (possibly 
parameterized)  models  of  program  units;  as  such  they  cannot  be  used  directly.  For  example  a 
gener  c subprogram  cannot  be  called.  Instances  li.e.  copies)  of  the  model  are  obtained  by  generic 
instantiation.  These  are  ordinary  subprograms  and  modules  that  can  be  used  directly 

A subprogram  or  module  can  be  designated  as  generic  by  the  inclusion  of  a generic  clause  in  its 
specification.  A generic  clause  can  include  the  definition  of  generic  parameters.  An  instance  of  a 
generic  unit  with  appropriate  actual  parameters  for  the  generic  formal  parameters,  is  obtained  as 
the  result  of  a subprogram  or  module  declaration  with  a generic  instantiation. 


12.1  Generic  Clauses 


A generic  clause  given  with  a subprogram  or  module  specification  specifies  that  the  unit  is  generic 
and  defines  any  generic  parameters. 

generic_clause  ::= 

generic  |(generic_parameter  |;  generic_parameter|)| 

generic_parameter  ;:= 

para  meter_decla  ration 

| subprogram_specification  |is  |name.)designator| 

| I restricted  I type  identifier 

The  usual  forms  of  parameter  declarations  available  for  subprogram  specifications  can  also  appear 
in  generic  clauses. 

Within  an  instantiated  unit,  an  in  or  in  out  parameter  provides  access  to  the  value  of  the  actual 
parameter,  an  out  or  in  out  parameter  permits  assignment  to  the  variable  given  as  actual 
parameter,  as  usual.  In  addition,  generic  parameters  can  denote  types  and  subprograms. 

A type  given  as  a generic  parameter  is  considered  as  a private  type  within  the  body  of  the  generic 
unit.  Hence,  if  any  operation  (apart  from  assignment  and  comparison  for  equality  or  inequality)  on 
objects  of  this  type  is  to  be  used  in  the  generic  body,  the  operation  must  also  be  provided  as  an 
additional  generic  parameter.  Neither  assignment  nor  the  predefined  comparison  for  equality  or 
inequality  is  available  if  the  generic  type  parameter  is  specified  as  restricted. 

On  the  other  hand,  a generic  parameter  of  a generic  clause  cannot  refer  to  a previous  generic 
parameter  of  the  same  clause  unless  this  previous  generic  parameter  denotes  a type.  Both  the 
specification  and  the  body  of  a generic  subprogram  or  module  can  refer  to  generic  parameters. 

Expressions  appearing  in  a generic  clause  are  evaluated  during  the  elaboration  of  the  clause  unless 
they  refer  to  a type  that  is  a generic  parameter  (for  example,  an  expression  that  is  an  attribute  of  a 
type);  such  expressions  are  evaluated  during  elaboration  of  generic  instantiations. 
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The  specification  of  a generic  parameter  that  is  a subprogram  may  provide  a designator  to  be  used 
by  default  upon  instantiation.  An  actual  parameter  is  optional  in  this  case;  in  the  absence  of  an 
actual  parameter  the  designator  supplied  in  the  generic  clause  is  used.  Such  a default  designator 
can  be  any  subprogram  matching  the  corresponding  subprogram  specification;  it  can  be  an 
attribute  of  a type  that  is  a generic  parameter.  Note  that  the  designator  can  be  prefixed  by  the 
name  of  a type  of  which  it  is  an  attribute. 

A non-local  name  in  the  body  of  a generic  unit  is  identified  during  the  elaboration  of  the  generic 
body.  A generic  unit  can  be  separately  compiled. 

Examples  of  generic  clauses: 

generic  --  parameterless 

genericISIZE  : INTEGER,  type  ELEM) 

generkILENGTH  ; INTEGER  :=  200)  ~ default  value 

generic!  type  T; 

function  "*"(X.Y:  T)  return  T) 
generic!  type  T; 

function  "*"(X,Y:  T)  return  T is  T."*")  — default  operator 

Examples  of  generic  subprograms: 

genericftype  ELEM) 

procedure  EXCHANGED.  V:  in  out  ELEM)  is 
T : ELEM; 

fetgift 

T :=  U;  U :=  V;  V :=  T; 

end  EXCHANGE; 

generic!  type  T; 

function  “*'(U.  V:  T)  return  T is  T.'O 
function  SQUARINGIX:  T)  return  T is 
pragma  INLINE; 
begin 

return  X * X; 
end  SQUARING; 

Example  of  generic  module: 

generic  tack  SEMAPHORE  is 
entry  P; 
entry  V; 
end; 


task  body  SEMAPHORE  is 


loop 

accgpt  P; 
accept  V; 
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/Votes: 


An  explicit  tormal  parameter  for  the  equality  operation  may  be  supplied.  In  the  case  of  an 
unrestricted  type  it  will  override  the  built-in  comparison  operation  In  the  case  of  a restricted  type 
it  allows  and  provides  the  comparison  operation 


12.2  Generic  Instantiation 


An  instance  of  a generic  program  unit  is  obtained  as  the  result  of  the  elaboration  of  a subprogram 
or  module  declaration  defined  in  terms  of  a generic  instantiation 

gt  neric_instantiation  : 

new  name  llgeneric. association  |.  generic. .association!)! 

generic_association  ::= 

parameter  .association 
| Itormal. parameter  is | (name. (designator 
| |tcrmal..parameter  is  I type  .mark 

The  forms  of  declarations  with  generic  instantiations  are  given  in  the  sections  on  subprogram 
declarations  (6.2)  and  modules  (7.1): 

subprogram  nature  designator  is  generic  instantiation: 

module  nature  identifier  |( discrete  range) I is  generic  instantiation: 

Actual  parameters  must  be  supplied  tor  each  generic  tormal  parameter  unless  the  corresponding 
generic  clause  specifies  a default.  Parameters  can  be  given  in  positional  form  or  in  named  form  as 
for  subprogram  calls  (see  5.2).  Each  actual  parameter  must  match  the  corresponding  generic  tor 
mal  parameter  A type  matches  a type;  a restricted  ictual  type  does  not  match  an  unrestricted  tor 
mal  type  For  subprogram  parameters  all  occurrences  of  the  name  of  a type  that  is  a tormal  generic 
parameter  are  replaced  by  the  corresponding  actual  parameter.  An  actual  subprogram  matches  a 
formal  subprogram  having  parameters  with  the  same  order,  mode.  type,  and  constraint  and  with 
the  same  result  tvoe  and  constraint  (the  parameter  names  and  default  values  being  ignored). 

An  actual  parameter  of  a generic  association  is  evaluated  during  elaboration  of  the  generic  instan 
tiation.  It  a formal  generic  parameter  is  used  in  the  generic  body  in  a context  which  requires  static 
evaluation,  the  corresponding  actual  parameter  must  be  a static  expression.  In  particular,  this  rule 
applies  to  default  expressions  given  for  optional  in  parameters. 

The  elaboration  of  a generic  instantiation  creates  an  instance  of  the  generic  unit  in  which  all 
generic  parameters  are  replaced  as  defined  above  by  the  parameters  supplied  in  the  generic 
associations.  The  specification  of  a module  or  subprogram  obtained  by  generic  instantiation  is 
derived  from  the  specification  of  the  corresponding  generic  unit  after  the  parameter  replacements 

Recursive  instantiation  of  generic  units  is  not  allowed. 

Examples  of  declarations  with  generic  instantiations : 

procedure  SWAP  ie  new  EXCHANGEIELEM  I*  INTEGER!: 

procedure  SWAP  la  new  EXCHANGE(CHARACTER);  SWAP  is  overloaded 
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s 


function  SQUARE  it  now  SQUARING) INTEGER);  - 0)  INTEGER  u«ni<  »lu 

function  SQUARE  ia  now  SQUARING(MATRIX.MATRIX_  PRODUCT),  U 

tack  SEMA  is  now  SEMAPHORE; 

Examples  of  the  use  of  instantiated  units. 


SWAPIX  Y); 

I SQUAREI8) 
SEMA  P 


12.3  Example  of  a Generic  Package 


Tht  following  example  provides  a possible  formulation  of  stacks  formulated 
ne  si*e  of  each  stack  and  the  type  of  the  stack  elements  are  provided  as 


as  a generic  package, 
generic  parameters 


gonericISIZE  INTEGER  type  ELEM) 
package  STACK  ie 

procedure  PUSHIE:  in  ELEM) 
procedure  POP  IE;  out  ELEM) 
OVERFLOW,  UNDERFLOW  exception 
end  STACK: 


package  body  STACK  ie 

SPACE  array  (1  SIZE)  of  ELEM; 
INDEX  : INTEGER  range  0 SIZE  :«  0 

procedure  PUSHIE:  in  ELEM)  is 

begin 

if  INDEX  = SIZE  then 
raise  OVERFLOW; 
and  if; 

INDEX  INDEX  + 1; 

SPACEIINDEX)  :=.  E; 
end  PUSH; 

' procedure  POPIE  out  ELEM)  is 

\ *»•«<" 

U INDEX  = 0 then 
raise  UNDERFLOW; 

and  if; 

E SPACEIINDEX); 

INDEX  :=  INDEX  - 1; 
end  POP; 

and  STACK, 


Instances  of  this  generic  module  can  be  obtained  as  follows: 


package  STACKJNT 
package  STACK_BOOL 


is  new  STACKISIZE  200,  ELEM  is  INTEGER) 
is  new  STACK!  100,  BOOLEAN); 
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Thereafter,  the  procedures  of  the  instantiated  packages  can  be  called  as  follows: 


STACKJNT.  PUCH(I) 

STACK_BOOL.PUSH(TRUE); 

Alternatively,  a generic  formulation  of  the  type  STACK  can  be  formulated  as  follows  (package  body 
omitted): 

genericISIZE  : INTEGER,  type  ELEM) 
package  ON.STACKS  is 
type  STACK  is  pr.vate; 

procedure  PUSH  (S:  in  out  STACK;  E:  in  ELEM); 
procedure  POP  (S:  in  out  STACK;  E:  out  ELEM); 

OVERFLOW,  UNOERFLOW  : exception: 
private 

type  STACK  is 
record 

SPACE  : array!  1 ..  SIZE)  of  ELEM; 

INDEX  : INTEGER  range  0 ..  SIZE  :=  0, 

end  record 

end: 


In  order  to  use  such  a package,  an  instantiation  must  be  created  and  thereafter  stacks  of  the  cor- 
responding type  can  be  declared  as: 

package  STACKJNT  is  new  ON_STACKS(SIZE  :=  100,  ELEM  is  INTEGER); 

An  example  of  the  use  of  the  instantiated  package  is  as  follows: 

Htclirf 

use  STACKJNT; 

S : STACK; 

begin 

PUSHIS,  20); 

end; 
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13.  R*pr«*«ntation  Specification*  and  Implamantation  Dependant  Feature* 


Representation  specifications  specify  the  mapping  between  data  types  and  features  of  the 
underlying  machine  that  executes  programs  Representation  specifications  can  be  more  or  less 
dire  in  some  cases,  they  completely  specify  the  mapping  in  other  cases  they  only  provide 
criteria  for  choosing  a mapping. 

Mappings  acceptable  to  an  implementation  do  not  alter  the  net  effect  of  a program  They  can  be 
provided  to  give  a more  efficient  representation  or  to  interface  with  features  that  are  outside  the 
domain  of  the  language  (for  example,  peripheral  hardware). 

representation_specification  ::= 

packing_specification  | length_specification 

I record_type_.representation  | enumeration_type_representation 
| address_specification 

Representation  specifications  must  appear  immediately  after  the  list  of  declarations  of  a 
declarative  part,  and  can  only  apply  to  items  declared  in  the  same  declarative  part.  A representa- 
tion specification  given  for  a type  applies  to  all  objects  of  the  type.  In  the  absence  of  explicit 
specifications,  repmsentations  are  determined  by  the  compiler 

All  representation  specifications  must  be  determinable  at  compilation  time.  In  particular,  expres- 
sions appearing  in  such  specifications  must  be  static  expressions  Depending  on  the  specification 
such  expressions  represent  either  a number  of  bits  or  a number  of  storage  units 

For  record  and  enumeration  types  derived  from  other  similar  types,  a representation  specification 
is  legal  only  if  the  derived  type  does  not  derive  user  defined  subprograms  from  its  parent  type  (see 
3.4).  In  addition,  implementations  may  limit  representation  specifications  to  those  that  can  be 
simply  handled  by  the  underlying  hardware 


13.1  Packing  Specification* 


A packing  specification  indicates  that  storage  minimization  should  be  the  main  criterion  for 
selecting  the  representation  of  a record  or  array  type. 

packing_specification  ::=  for  type_ name  us*  packing. 

This  means  that  gaps  between  the  storage  places  allocated  to  consecutive  components  should  be 
minimized  However,  it  does  not  affect  the  mapping  of  each  component  on  storage.  This  mapping 
can  only  be  influenced  by  a representation  specification  for  the  component  type. 

The  predefined  type  STRING  is  packed. 
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Examples: 

lor  MATRIX  un  packing; 

for  FILE  .DESCRIPTOR  un  packing; 


1 3.2  Length  Specifications 


A length  specification  controls  the  amount  of  storage  associated  with  a named  entity. 

length_specification  for  name  use  5far/c_expression; 

The  name  must  be  one  of  the  following: 

(a)  Name  of  a type  that  is  not  an  access  type: 

The  value  of  the  expression  specifies  the  maximum  number  of  bits  to  be  allocated  to  objects 
of  the  type.  This  number  must  be  at  least  equal  to  the  minimum  needed  for  the  representation 
of  objects  of  the  type.  This  form  of  length  specification  can  be  used  to  achieve  a biased 
representation. 

(b)  Name  of  an  access  type: 

The  value  of  the  expression  is  the  number  of  bits  to  be  reserved  for  the  collection,  i.e.  the 
space  for  all  objects  of  that  access  type. 

Note  that  dynamic  objects  allocated  in  a collection  need  not  occupy  the  same  storage  if  they 
are  records  with  variants  or  dynamic  arrays.  Note  also  that  the  allocator  itself  may  require 
some  space.  Hence,  the  length  specification  does  not  always  give  precise  control  over  the 
maximum  number  of  allocated  objects 

(c)  Name  of  a task: 

The  value  of  the  expression  is  the  number  of  bits  to  be  reserved  for  an  activation  of  the  task. 
The  method  of  allocation  is  not  defined  (for  example,  a stack,  a general  storage  allocator,  or 
fixed  storage  could  be  used). 


The  exception  STORAGE_OVERFLOW  is  raised  if  a task  or  access  type  exceeds  the  reserved 
space. 

Examples: 


assumed  declarations: 

type  BIASED  ia  new  INTEGER  range  10_000  ..  10_255; 
type  SHORT  ie  delta  0.01  range  -100.0  ..  100.0; 

BYTE  : conatant  INTEGER  :=  8; 

PAGE  : conatant  INTEGER  1000  * SYSTEM 'ST0RAGE_U NIT; 
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— length  specifications: 


for  COLOR  use  1 *BYTE; 
for  ELEMENT  um  INTEGER  SIZE 
for  BIASED  um  1*BYTE; 


for  PRINTER  um  4*PAGE; 

for  CAR  um  2000*CAR  SIZE; 


for  SHORT  um  1 5; 


- biased  representation 


- space  for  approximately  2000  cars 


Notes: 


i?nnhe7a?»eXariP,e'  l5  b‘tS  18  aCtU8l,y  th®  minimum  numb«r  of  necessary  bits  for  SHORT  since  £ 

provide  , ° P°'nt'  a"d  l belOW  th®  P°int  are  needed  An  implementation  need  noi 

provide  the  ability  to  reserve  just  the  minimum,  because  of  the  masking  code  needed 


13.3  Enumeration  Type  Representations 


An  enumeration  type  representation  specifies  the  internal  codes  for  the  literals  of  an  enumeration 
type. 


enumeration_type_representation  for  fype_name  um  aggregate; 

The  aggregate  used  to  specify  this  mapping  is  an  array  aggregate  of  type 
array  <fype_name)  of  INTEGER 


All  enumeration  literals  must  be  provided  with  distinct  integer  codes,  and  the  aggregate  must  be  a 
s atic  expression.  The  integer  codes  specified  for  the  enumeration  type  must  satisfy  the  ordering 
relation  of  the  type.  The  aggregate  must  be  named  when  the  enumeration  type  has  a single  literal 


Example : 

type  MIX_C0DE  is  (ADD,  SUB,  MUL,  LDA,  STA.  STZI; 
for  MPCCODE  um 

(ADD  =>  1.  SUB  = > 2,  MUL  =>  3,  LDA  =>  8,  STA  =>  24,  STZ  =>  33); 


Notes : 


The  predefined  attributes  SUCC,  PRED,  and  ORD  are  defined  even  for  enumeration  types  with  a 
"°n 'cor\t,9uous  representation.  In  this  case,  the  functions  are  less  efficiently  implemented  due  to 
indexhg  t0  aV°'d  ^ °m,tted  va,ues-  Similar  considerations  apply  when  such*  types  are  used  for 
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1 3.4  Record  Type  Representation* 


A record  type  representation  specifies  the  storage  representation  of  records,  that  is,  the  order 
position,  and  sire  of  record  components. 

record_type_representation  ::= 
for  rype_name  us* 

record  lalignment_clause;j 
\component .name  location  ) 

•nd  record 

location  at  static-expression  range  range 
alignment_clause  ::=  at  mod  srar/c_ expression 

The  position  of  a component  is  specified  as  a location  relative  to  the  start  of  the  record;  the  at 
clause  defines  the  address  of  a storage  unit  and  the  range  defines  the  bit  positions  of  the  compo- 
nent relative  to  the  storage  unit. 

The  first  storage  unit  of  a record  is  numbered  0.  The  first  bit  of  a storage  unit  is  numbered  0.  The 
ordering  of  bits  in  a storage  unit  is  machine  dependent  and  may  extend  to  adjacent  storage  units. 
For  a specific  machine,  the  size  in  bits  of  a storage  unit  is  given  by  the  configuration  dependent 
constant  SYSTEM'STORAGE_UNIT. 

Locations  may  be  specified  for  some  or  for  all  components  of  a record.  If  no  location  is  specified  for 
a component,  freedom  is  left  to  the  compiler  to  define  the  location  of  the  component.  Locations 
within  a record  variant  must  not  overlap,  but  the  storage  for  distinct  variants  may  overlap.  Each 
location  must  allow  for  enough  storage  space  to  accommodate  every  allowable  value  of  the  com- 
ponent. 

An  alignment  clause  forces  each  record  of  the  given  type  to  be  allocated  at  a start  address  which  is 
a multiple  of  the  value  of  the  expression  (i.e.  the  address  modulo  the  expression  must  be  zero).  An 
implementation  may  place  restrictions  on  the  allowable  alignments.  Components  may  overtap 
storage  boundaries,  but  an  implementation  may  place  restrictions  on  how  components  may 
overlap  storage  boundaries. 

Examples: 


WORD  constant  INTEGER  :=  4 — storage  unit  is  byte,  4 bytes  per  word 

typ*  STATE  it  (A.  M,  W.  P); 

typ*  MODE  it  (FIX,  DEC,  EXP,  SIGNIF); 


typ*  PROGRAM_STATUS__WORD  it 

record 


system_mask 

PROTECTION-KEY 

MACHINE-STATE 

INTERRUPT_CAUSE 

ILC 

CC 

PROGRAM-MASK 

INST-ADDRESS 

and  record; 


array(0  7)  of  BOOLEAN; 

INTEGER  rang*  0 ..  3; 

array(STATE'FIRST  ..  STATE  LAST)  of  BOOLEAN- 
INTERRUPTION-CODE; 

INTEGER  rang*  0 ..  3; 

INTEGER  rang*  0 ..  3; 

*wy(MODE'FIRST  ..  MODE-LAST)  of  BOOLEAN- 
Ai  DRESS; 
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lor  PROGRAM_STATUS_WORD  um 
record  at  mod  8: 


SYSTEM-MASK 

at 

O.WORD 

range 

0 

7; 

PROTECTION-KEY 

at 

O.WORD 

range 

10 

..  11. 

MACHINE -STATE 

at 

O.WORD 

range 

12 

15; 

INTERRUPT  _CAUSE 

at 

O.WORD 

range 

16 

. 31: 

ILC 

at 

1 .WORD 

range 

0 

1; 

CC 

at 

1 .WORD 

range 

2 

3; 

PROGRAM-MASK 

at 

1 .WORD 

range 

4 ,. 

7. 

INST-ADDRESS 

at 

1 .WORD 

range 

8 

31; 

and  record; 


bits  8 9 unused 

second  word 


13.5  Address  Specifications 

An  address  specification  defines  the  location  of  an  object  in  storage  or  the  start  address  of  a 
program  unit. 

8ddress_specification  ::  for  name  use  at  sfaf/'c_expression; 

The  at  clause  specifies  an  absolute  address  expressed  in  storage  units  in  an  implementation 
defined  address  space.  The  name  must  be  one  of  the  following: 


(a)  Name  of  a variable;  in  this  case,  the  address  is  the  address  of  the  variable. 

(b)  Name  of  a subprogram  or  module:  the  address  is  that  of  the  machine  code  associated  with 
the  subprogram  or  module. 

(c)  Name  of  an  entry:  The  address  is  that  of  a hardware  interrupt  to  which  the  entry  is  linked.  The 
conventions  defining  the  mapping  between  the  integer  value  of  the  expression  and  the  inter 
rupt  are  implementation  dependent. 


13.5.1  Interrupts 


An  interrupt  acts  as  an  entry  call.  An  accept  statement  for  such  an  entry  results  in  suspension  of 
the  task  until  the  interrupt  occurs.  If  control  information  is  supplied  by  the  interrupt,  then  this  must 
appear  as  an  in  parameter  of  the  entry.  Multiple  interrupts  are  queued  on  the  corresponding  entry 
There  may  be  an  implementation  defined  limit  for  the  number  of  allowed  pending  interrupts  on  a 
given  entry. 

Example  of  interrupt  specification : 

task  CARD-READER -INTERRUPT  Is 
entry  ATTENTION; 
end: 
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task  body  CARD_READER_INTERRUPT  is 
entry  DONE; 
for  DONE  un  at  4 
begin 
loop 

accept  ATTENTION: 

select 

accept  DONE; 

CARD_REAOER  EMPTY 

or 

delay  2.SEC; 

CAR  D_READER.  FINISH; 

and  select 
end  loop; 

end  CARD_READER_INTERRUPT, 


13.6  Change  of  Representations 


Only  one  representation  can  be  defined  for  a given  type.  In  consequence  if  an  alternative  represen- 
tation is  desired,  it  is  necessary  to  declare  a second  type  derived  from  the  first  and  to  specify  a dif- 
ferent representation  for  the  second  type. 

Example: 

- PACKED_DESCRIPTOR  and  DESCRIPTOR  are  two  different  types 

— with  identical  characteristics,  apart  from  their  representation 

type  DESCRIPTOR  is 

record 

— components  of  a descriptor 

end 


type  PACKED_DESCRIPTOR  is  new  DESCRIPTOR 
for  PACKED_DESCRIPTOR  use  packing; 

Change  of  representations  can  now  be  accomplished  by  assignment  with  explicit  type  conversions. 
Thus: 

D : DESCRIPTOR. 

P : PACKED_DESCRIPTOR; 

P :=  PACKED_DESCRIPTOR(D);  - pack 

D :=  DESCRIPTOR(P):  --  unpack 

13.7  Configuration  and  Machine  Dependent  Constants 


The  characteristics  of  the  configuration  can  be  specified  by  supplying  appropriate  pragmas: 


pragma  SYSTEMIname); 
pragma  STORAGE_UNIT(number); 
pragma  MEMORY_SIZE!number); 


— to  establish  the  name  of  the  object  machine 

— to  establish  the  number  of  bits  per  storage  unit 

— to  establish  the  available  number  of  storage  units 


The  values  of  configuration  dependent  constants  are  denoted  by  predefined  attributes  of  the 
predefined  name  SYSTEM.  Similarly,  compiler  options  may  be  interrogated  with  boolean 
attributes  of  the  predefined  name  OPTION. 

SYSTEM'NAME  --  the  name  of  the  object  machine 

SYSTEM'STORAGE_UNIT  --  the  number  of  bits  per  storage  unit 

SYSTEM'MEMORY_SIZE  --  the  number  of  available  storage  units  in  memory 

OPTIONSPACE  - true  if  space  is  the  optimization  criterion 

OPTIONTIME  — true  if  time  is  the  optimization  criterion 

Other  implementation  dependent  characteristics  of  specific  program  constructs,  including  the 
characteristics  established  by  representation  specifications,  can  be  determined  using  appropriate 
attributes.  An  implementation  may  provide  additional  predefined  attributes  specific  to  the  machine 
considered.  The  list  of  the  predefined  attributes  that  are  defined  by  the  language  is  given  in  appen- 
dix A. 

Examples: 

INTEGERSIZE  - number  of  bits  actually  used  for  implementing  INTEGER 

TABLE  ADDRESS  --  the  address  of  TABLE  in  storage  units 

X.COMPONENT POSITION  - position  of  COMPONENT  in  storage  units 

X.COMPONENTFIRST_BIT  - first  bit  of  bit  range 

X. COMPONENT LAST_BIT  - last  bit  of  bit  range 


13.8  Machine  Code  Insertions 


A machine  code  insertion  may  be  achieved  by  a call  to  an  inline  procedure  whose  body  contains 
only  code  statements. 

code^statement  ::=  quelifiecLexpression; 

Each  machine  instruction  appears  as  a record  aggregate  of  a record  type  defining  the  cor- 
responding instruction.  Declarations  of  such  record  types  will  generally  be  available  in  a predefined 
package  for  each  machine.  A procedure  that  contains  a code  statement  must  contain  only  code 
statements. 

An  implementation  may  provide  machine  dependent  pragmas  specifying  register  and  calling  con- 
ventions. 

Example: 


M:  MASK; 

procedure  SET_MASK  is 
use  INSTRUCTI0N_360; 
pragma  INLINE; 


SLFORMATICODE  =>  SSM,  B =>  MBASE.  D =>  M DISP); 

- M BASE  and  M'DISP  are  implementation  specific  predefined  attributes 

end; 
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13.9  Interface  to  Other  Langutgn 


A subprogram  written  in  another  language  can  be  called  from  a Green  program  provided  that  all 
communication  is  achieved  via  parameters  and  result.  A procedure  skeleton  must  be  provided  tor 
such  foreign  subprograms  This  skeleton  must  include  a subprogram  specification  in  the  usual 
form,  thus  enabling  other  subprograms  to  call  it.  The  sequence  of  statements  of  this  skeleton  must 
reduce  to  a pragma  specifying  the  foreign  language. 

For  example,  the  Fortran  subprogram 

SUBROUTINE  GAUSS(AX.N) 

DIMENSION  A(1 0.10),  XI 101 

END 

can  be  represented  by  the  followinq  skeleton 

type  MATRIX  it  array  (INTEGER  INTEGER)  of  REAL' 
type  VECTOR  it  array  (INTEGER)  of  REAL; 

procedure  GAUSSIA  in  out  MATRIX;  X : in  out  VECTOR;  N : INTEGER)  it 

b«gin 

INFERFACEIFORTRAN); 


The  pragma  specifies  the  calling  convention  to  be  used,  and  informs  the  compiler  that  an  object 
module  will  be  provided  for  the  corresponding  subprogram. 

This  capability  need  not  be  provided  by  all  compilers;  an  implementation  may  place  restrictions  on 
the  allowable  forms  and  places  of  parameters  and  calls. 


13.10  Unaafa  Typo  Conversion 

Unsafe  type  conversions  can  be  achieved  by  program  units  having  access  to  the  predefined  library 
module  UNSAFE-.PROGRAMMING  by  instantiating  the  generic  function  UNSAFE_CON VER- 
SION 


package  UNSAFE-PROGRAMMING  it 

generic  (type  S ; type  T) 
function  UNSAFE-CONVERSION  (X 

end  UNSAFE_PROGRAMMING; 


S)  return  T; 


unsa/f  PPnrStMMiM?  th!  vis,bllitv  rules  that  such  program  units  must  include 
UNSAFE_PROGRAMMING  in  their  visibility  list. 
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14.  Input-Output 


(This  chapter  describes  the  input-output  facilities  defined  in  the  language.  The  standard  generic 
package  INPUT_OUTPUT  defines  a set  of  input-output  primitives  applicable  to  files  containing  ele 
ments  of  a single  type.  Additional  primitives  for  text  input-output  are  supplied  in  the  standard  pac- 
kage TEXT_IO.  These  facilities  are  described  here  as  well  as  the  conventions  to  be  used  for  dealing 
with  low  level  input-output  operations. 


14.1  General  User  Level  Input-Output 


The  high  level  input-output  facilities  are  defined  in  the  language  A suitable  package  is  described 
here  and  is  given  explicitly  in  section  14.2;  it  defines  file  types  and  the  procedures  and  functions 
which  operate  on  files. 

Files  are  declared  and  associated  with  appropriate  sources  and  destinations  (called  external  files) 
such  as  peripheral  devices  or  data  sets.  Distinct  file  types  are  defined  to  provide  either  read-only 
access,  write-only  access  or  read-and-write  access  to  external  files  The  corresponding  file  types 
are  called  IN_FILE,  OUT.FILE,  and  INOUT_FILE. 

At  this  level,  external  files  are  named  by  a character  string,  which  is  interpreted  by  individual  imple- 
mentations to  distinguish  peripherals,  access  rights,  physical  organization,  etc. 

The  package  defining  these  facilities  is  generic  and  is  called  INPUT_OUTPUT.  Any  program  which 
requires  these  facilities  must  instantiate  the  package  for  the  appropriate  element  type. 

A file  can  be  read  or  written,  and  it  can  be  set  to  a required  position;  the  current  position  for  access 
and  the  number  of  elements  in  the  file  may  be  obtained. 


14.1.1  Files 


A file  is  associated  with  an  ordered  collection  of  elements,  all  of  the  same  type.  The  type  of  the  ele 
ments  is  specified  as  a parameter  in  the  package  declaration,  so  that  appropiiate  procedures  are 
produced  for  dealing  with  elements  of  that  type,  as  well  as  the  file  types.  For  example. 

it 

'I 


J 
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package  INTJO  is  new  INPUT_OUTPUT(INTEGERI. 


1 


establishes  types  and  procedures  for  tiles  of  integers,  so  that 
IN7_FIIE  : INTJO  OUT_FILE; 
declares  INT_FILE  as  a write-only  file  of  integers 

Before  any  file  processing  can  be  carried  out.  the  file  must  be  associated  with  an  external  file. 

When  such  an  association  is  in  effect  the  file  is  said  to  be  open.  This  operation  is  performed  by  one 
of  the  following  two  procedures: 

CREATE  establishes  a new  external  file  and  associates  the  given  file  with  it.  If  the  given  file 

is  already  open,  the  exception  FILE_OPEN_ERROR  is  raised.  If  creation  is 
prohibited  for  an  external  file  because  it  already  exists  or  for  any  other  reason,  the 
exception  FILE_NAME_ERROR  is  raised.  (CREATE  is  no,  defined  for  an  IN_FILE.) 

OPEN  associates  the  given  file  with  an  existing  external  file.  If  the  given  file  is  already 

open,  the  exception  FILE_OPEN_ERROR  is  raised.  If  no  such  file  exists  or  this 
access  is  prohibited,  the  exception  FILE_NAME_ERROR  is  raised. 

Any  file  operation  that  cannot  be  completed  because  of  difficulties  in  the  underlying  system  raises 
the  exception  MALFUNCTION.  Any  attempt  to  carry  out  an  operation  that  is  physically  impossible 
or  prohibited  raises  the  exception  FILE_USE_ERROR 

Whether  a file  is  currently  associated  with  an  external  file  may  be  discovered  by  the  following  func- 
tion: 

IS_OPEN  returns  TRUE  if  there  is  an  associated  file,  FALSE  otherwise. 

All  operations  described  subsequently  apply  to  open  files.  Any  attempt  to  use  them  on  a file  that  is 
not  open  raises  the  FILE_OPEN_ERROR  exception. 

The  name  of  the  external  file  currently  associated  with  a given  file  can  be  discovered  by  the  func- 
tion: 

NAME  returns  a string  representing  the  name  of  the  external  file  currently  associated  with 

the  argument. 

After  processing  has  been  completed  on  a file,  the  association  may  be  broken  by  one  of  the  follow- 
ing two  procedures: 

CLOSE  breaks  the  association  between  the  file  and  its  associated  external  file.  The  exter- 

nal file  continues  to  exist. 

DELETE  breaks  the  association  between  the  file  and  its  associated  external  file.  The  exter- 

nal file  is  deleted. 

Example  1 : Create  a New  External  File  on  Backing  Store 

CREATEIFILE  :=:  INT_FILE,  NAME  :=  ”>udd'>ada> counts"); 

— write  the  file 
CLOSE(INT_FILE); 

I 


I 


Example  2 Read  a Paper  Tape 

declare 

package  CHARJO  it  new  INPUT_OUTPUT(CHARACTERI 
PT  CHARJO  IN_ FILE 

begin 

CHAR  JO  OPENIPT  "ttvo  > 

— input  the  file  from  device  ttyg 
CHAR_IO  CLOSE(PT); 

end; 


14.1.2  File  P roc  easing 


An  open  file  has  a current  size  and  a current  position.  The  size  of  a file  is  the  total  number  of  ele- 
ments currently  in  it.  The  current  position  of  the  file  determines  the  next  element  to  be  read  or 
written.  Each  element  occupies  one  position,  counting  from  1 After  the  last  element  of  a file  has 
been  read  or  written,  the  next  element  position  equals  the  size  of  the  file  plus  one 

The  following  subprograms  are  available  for  input-output  and  for  handling  the  size  and  position  of 
a file: 


READ  obtains  the  next  element  value  from  the  external  file  and  advances  the  position  by 

one.  If  there  is  no  such  element  then  the  exception  END_OF_FILE  is  raised  If  the 
next  element  is  not  of  the  proper  type  then  the  exception  INVAUD_DATA  is  raised 
(READ  is  not  defined  for  an  OUT_FILE;  for  an  INOUT_FILE.  any  previous  WRITE 
must  have  been  completed.) 

WRITE  gives  the  next  element  in  the  external  file  the  specified  value  and  advances  the 

position  by  one,  adjusting  the  size  of  the  file  if  necessary.  (WRITE  is  not  defined  for 
an  IN_FILE.) 


SIZE  returns  the  number  of  elements  currently  in  the  file 

NEXT  returns  the  current  position  of  the  file. 

SEt-NEXT  moves  the  file  so  that  the  next  element  read  or  written  will  be  frrm  the  position 
specified.  If  the  position  value  specified  does  not  exist  in  the  current  file,  a subse 
quent  READ  will  raise  an  exception  (a  subsequent  WRITE  may  raise  an  exception) 
SET_NEXT  has  a default  position  corresponding  to  the  first  element  of  the  file  This 
procedure  can  be  used  to  rewind  backspace,  or  advance  the  file 


Examples  of  file  positioning: 


SET_NEXT(INT_FILE); 
SET_NEXT(INT_FILE,  NEXT|INT_FILE)-1); 
SET_NEXT(INT_FILE.  SIZE(INT_ FILE)  + 1 ) 


rewind  (set  to  position  II 

backspace 

advance  to  end  of  file 
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Example  of  file  processing 


Accumulate  the  values  in  a file  and  append  the  total 

declare 

use  INT  JO 

COUNTS  INOUT_FILE: 

VALUE  INTEGER: 

TOTAL  : INTEGER  :=  0; 

begin 

OPEN  (COUNTS,  ">udd>ada'>  counts"); 

loop 

REAOICOUNTS,  VALUE); 

TOTAL  :=  TOTAL  + VALUE, 

end  loop 
exception 

when  END_OF_FILE  => 

WRITE  (COUNTS.  TOTAL), 

CLOSE  (COUNTS); 

end 


14.2  Specification  of  the  Package  INPUT  OUTPUT 


The  specification  of  the  generic  standard  package  INPUT_OUTPUT  is  given  below.  It  provides  the 
calling  conventions  for  all  operations  described  in  section  14  1. 


generic  (type  ELEMENT-TYPE) 
package  INPUT_OUTPUT  is 


restricted 

type  IN_FILE 

is 

private; 

restricted 

type  OUT, 

-FILE 

is 

private; 

restricted 

type  INOUT_FILE 

is 

private; 

— Global  operations  for  file  manipulation 

procedure 

CREATE 

(FILE 

in 

out  OUT_FILE; 

NAME  : in 

STRING); 

procedure 

CREATE 

(FILE 

in 

out  INOUT_FILE; 

NAME  . in 

STRING); 

procedure 

OPEN 

(FILE 

in 

out  IN_FILE; 

NAME  : in 

STRING); 

procedure 

OPEN 

(FILE 

in 

out  OUT_FILE; 

NAME  : in 

STRING); 

procedure 

OPEN 

(FILE 

in 

out  INOUT.FILE; 

NAME  : in 

STRING); 

procedure 

CLOSE 

(FILE 

in 

out  IN.FILE); 

procedure 

CLOSE 

(FILE 

in 

out  0UT_FILE); 

procedure 

CLOSE 

(FILE 

in 

out  INOUT_FILE); 

function 

IS_OPEN  (FILE 

in 

IN_FILE)  return  BOOLEAN; 

function 

IS_OPEN(FILE 

in 

OUT_FILE)  return 

BOOLEAN; 

function 

IS_OPEN(FILE 

in 

INOUT_FILE)  return  BOOLEAN; 

function 

NAME 

(FILE 

in 

IN_FILE)  return  STRING; 

function 

NAME 

(FILE 

in 

OUT_FILE)  return 

STRING; 

function 

NAME 

(FILE 

in 

INOUT_FILE)  return  STRING; 

function 

SIZE 

(FILE 

in 

IN_FILE)  return  INTEGER; 

function 

SIZE 

(FILE 

in 

OUT_FILE)  return 

INTEGER; 

function 

SIZE 

(FILE 

in 

INOUT-FILE)  return  INTEGER: 

14-4 


— input  and 

output 

subprograms 

procedure 

READ 

(FILE 

in 

IN_FILE: 

ITEM 

out  ELEMENT_TYPEI: 

procedure 

READ 

(FILE 

in 

INOUT_FlLE; 

ITEM 

out  ELEMENT_TYPE); 

procedure 

WRITE 

ifiIe 

in 

OUT_FILE; 

ITEM 

In  ELEMENT_TYPE); 

procedure 

WRITE 

(FILE 

in 

INOUT_FILE; 

ITEM 

in  ELEMENT_TYPE); 

function 

NEXT 

(FILE 

in 

IN_FILE)  return  INTEGER; 

function 

NEXT 

(FILE 

in 

OUT_FILEI  return  INTEGER; 

function 

NEXT 

(FILE 

in 

INOUT_FILE) 

return 

INTEGER: 

procedure 

SET_NEXT(FILE 

in 

IN_FILE; 

POS  : 

in  INTEGER  :=  1|; 

procedure 

SET_NEXT(FILE 

in 

OUT_FILE. 

POS 

in  INTEGfcR  :=  1). 

procedure 

SET_NEXT(FILE 

in 

INOUT.FILE; 

POS 

in  INTEGER  :=  11: 

— exceptions  that  can  be  raised 


FILE_NAME_ERROR 

FILE_USE_ERROR 

FILE_OPEN_ERROR 

INVALID_DATA 

MALFUNCTION 

END_OF_FILE 


exception; 

exception; 

exception; 

exception; 

exception; 

exception; 


private 

— declarations  of  the  file  private  types 
end  INPUT_OUTPUT; 


14.3  Text  Input-Output 


Facilities  are  available  for  input  and  output  in  human  readable  form,  with  the  external  file  con- 
sisting of  characters.  These  are  provided  in  a package  given  in  section  14.4  and  explained  here. 
This  package  defines  character  file  types  and  the  procedures  and  functions  which  put  and  get 
values  of  objects  in  and  out  of  such  files 

The  package  defining  these  facilities  is  called  TEXTJO.  It  uses  the  general  INPUT_OUTPUT 
package  for  files  of  type  CHARACTER,  so  that  all  the  facilities  described  in  section  14.1  are 
available.  In  addition  to  these  general  facilities  procedures  are  provided  to  GET  and  PUT  values  of 
suitable  types,  carrying  out  conversions  between  the  internal  values  and  appropriate  character  str- 
ings. 

All  the  GET  and  PUT  procedures  have  an  ITEM  parameter  whose  type  determines  the  details  of  the 
action  and  the  appropriate  character  string  in  the  external  file.  Note  that  the  ITEM  parameter  is  an 
out  parameter  in  GET  and  an  in  parameter  for  PUT.  The  general  principle  is  that  the  characters  in 
the  external  file  are  composed  and  analyzed  as  lexical  elements,  as  described  in  chapter  2.  The 
conversions  are  based  on  the  REP  and  VAL  attributes  described  in  Appendix  A. 

For  ati  GET  and  PUT  procedures,  there  are  forms  with  and  without  a file  specified.  If  a file  is 
specified,  it  must  be  of  the  correct  type  (IN_FILE  for  GET.  OUT_FILE  for  PUT)  If  no  file  is  specified, 
a default  input  or  output  file  is  used.  At  the  beginning  of  program  execution,  the  default  input  and 
output  files  are  the  so-called  standard  input  and  output  files,  which  are  associated  with  two 
implementation  defined  external  files. 
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14.3.1  Standard  Input  and  Output  Files 


The  particular  files  used  as  default  for  the  short  forms  of  GET  and  PUT  can  be  manipulated  by  the 
following  functions  and  procedures: 

function  STANDARD, INPUT  return  IN_FILE;  - returns  initial  default  in-file, 

function  STANDARD_OUTPUT  return  OUT_FILE;  — returns  initial  default  out-file, 

procedure  SET_INPUT  (FILE  : in  IN_FILE):  — sets  the  default  in-file 

procedure  SET_OUTPUT  (FILE  in  OUT_FILF).  — sets  the  default  out-file 


14.3.2  Layout 


The  characters  in  the  file  are  considered  to  form  a sequence  of  lines.  The  characters  in  each  line 
are  considered  to  occupy  consecutive  columns,  counting  from  1.  The  lines  in  each  file  are  counted 
from  1 . A file  may  have  a particular  line  length  that  is  explicitly  set  by  the  user.  If  no  line  length  has 
been  specified,  lines  can  be  of  any  length  up  to  the  size  of  the  file.  During  file  processing,  a file  has 
a current  line  number  and  a current  column  number.  These  determine  the  starting  position  avai- 
lable for  the  next  GET  or  PUT  operation. 

The  characters  in  the  file  consist  of  printable  (graphic)  characters  and  control  characters.  Each 
printable  character  or  space  is  associated  with  one  column.  The  control  characters  have  specific 
implications  on  the  line  and  column  numbers: 

CR  resets  the  column  number  to  one. 

LF  increments  the  line  number  by  one. 

BS  decrements  the  column  number  by  one  if  it  is  greater  than  one. 

TAB  increments  the  column  number  to  the  next  multiple  of  8 unless  that  would  take  it  beyond 
the  line  length  or  the  end  of  line  in  an  input  file,  in  which  case  it  increments  only  to  the  end 
of  the  line. 

Other  control  characters  do  not  affect  the  column  number  or  line  number. 

Layout  primitives  manipulate  the  line  structure  of  the  file  specified  by  the  first  parameter. 

LINE  returns  the  current  line  number 

COL  returns  the  current  column  number 

SET_LINE  sets  the  current  line  to  the  value  specified  by  the  second  parameter. 

The  current  column  is  set  equal  to  1. 

SET_COL  sets  the  current  column  to  the  value  specf!eu  by  the  second  parame- 

ter. The  current  line  is  unaffected. 

SET_LINE„LENGTH  sets  the  line  length  to  the  value  specified  by  the  second  parameter. 

Subsequently,  if  a SET_COL  operation  causes  the  column  number  to 
exceed  the  specified  line  length,  the  exception  INVALID_LAYOUT  is 

raised. 
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In  addition,  the  predefined  string  NEWLINE  corresponds  to  the  sequence  of  characters  used  to 
denote  the  end  of  a line  in  a given  implementation. 

Examples- 

SET_LINE(F.  LINE(F)+1);  --  advances  to  the  next  line 

SET_COL(F,  20);  advances  lor  backs  up)  to  column  20  on  the  current  line 

SET_COL(F.  COL(F)  +•  10);  --  advances  10  columns  forward 
SET_IINE_LENGTH(F.  132); 

PUT(NEWLINE);  — starts  a new  line  on  standard  output 


14.3.3  Input-Output  of  Characters  and  Strings 


The  GET  and  PUT  procedures  for  these  types  work  with  individual  characters,  which  may  be  prin- 
table or  control  characters,  and  affect  the  current  column  and  line  number  in  accordance  with  the 

particular  characters  processed  (never  going  outside  the  permitted  range). 

For  an  ITEM  of  type  CHARACTER 

GET  returns  the  value  of  the  next  character  from  the  input  file.  If  the  line  length  is  not  fixed,  this 
is  the  character  corresponding  to  the  current  position  on  the  file.  If  the  line  length  is  fixed, 
end  of  line  marks  are  skipped  and  the  next  character  is  the  one  on  the  current  column,  or 
on  the  first  column  of  the  next  line  if  the  last  column  read  corresponded  to  an  end  of  line. 

PUT  outputs  the  character  given  as  argument  to  the  file.  If  the  line  length  is  not  fixed,  the 
character  is  output  on  the  current  column  of  the  current  line  and  the  current  column  is 
updated  according  to  fhe  rules  given  in  14.3.2  above,  tf  the  line  length  is  fixed,  the 
character  is  output  similarly  and  the  current  column  is  aiso  updated  according  to  the  above 
rules,  except  if  such  a modification  would  cause  the  column  number  to  become  larger  than 
the  line  length.  In  the  latter  case  the  line  number  is  incremented  by  1 and  the  column 
number  is  reset  to  1 (an  automatic  new  line  is  inserted).  If  the  file  cannot  accept  the 
character,  the  exception  FllE_USE_ERROR  is  raised. 

When  the  ITEM  type  is  a string,  the  length  of  the  string  is  determined  and  that  exact  number  of 

GET  or  PUT  operations  for  individual  characters  is  carried  out. 

Example  1 : variable  line  length-. 

PUT(F,  "01234567"  & NEWLINE  & "89012345"); 

will  output 

01234567 

89012345 

If  the  file  is  subsequently  read,  the  whole  string  can  be  obtained  by 
X : STRINGd  ..  18); 

GET(F,  X); 

(assuming  NEWLINE  is  the  string  CR  & LF,  i.e.,  two  characters). 
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Example  2 fixed  line  /anyth  of  8 

PUT|F.  0123456789012345  ) 

will  output 

01234567 

89012345 

A subsequent  read  ot  that  text,  with  tho  same  line  length,  could  be  performed  by 
X STRING!  1 ..  16) 

C.ETIF  X): 


Note  that  the  double  quote  marks  enclosing  an  actual  parameter  to  PUT  are  not  output,  but  tho 
string  inside  is  output  with  any  doubled  double  quote  marks  written  once,  thus  matching  the  rule 
for  character  strings  (see  2 5) 


14.3.4  Input  Output  for  Other  Types 


All  ITEM  types  other  than  CHARACTER  or  STRING  are  treated  in  a uniform  way,  as  lexical  units 
(see  2.2.  2.3  2 4)  The  output  is  a character  string  having  the  syntax  described  for  the  appropriate 
unit  and  tho  input  is  taken  as  the  longest  possible  character  string  having  the  required  syntax.  For 
input,  any  leading  space,  TAB,  CR,  or  LF  characters  are  ignored.  A consequence  is  that  no  such 
units  can  cross  a line  boundary,  and  the  line  number  is  not  changed  by  them. 

If  the  character  string  read  is  not  consistent  with  the  syntax  of  the  required  lexical  unit,  the  excep 
tion  INVALID  DATA  is  raised. 

The  PUT  procedures  for  numeric  and  enumeration  types  include  on  optional  WIDTH  parameter, 
which  specifies  a minimum  number  of  characters  to  be  generated.  If  the  width  given  is  larger  than 
the  string  representation  of  the  value,  tho  value  will  be  preceded  (for  numeric  types)  or  followed 
(for  enumeration  typo)  by  the  appropriate  number  of  spaces.  If  the  field  width  is  smaller  than  tho 
string  representation  of  the  value,  the  field  width  is  ignored.  In  all  cases,  the  string  printed  is  prece 
ded  by  a space,  except  at  the  first  column  of  a line.  A default  width  of  0 is  provided,  thus  giving  the 
minimum  number  of  characters. 

In  each  PUT  operation,  if  the  line  can  accommodate  all  the  characters  genorated,  then  the  charac- 
ters are  placed  on  that  line  from  the  current  column.  If  the  line  cannot  accommodate  all  the  cha- 
racters, then  a new  lino  is  started  and  the  characters  are  placed  on  the  new  lino  starting  from 
column  1. 
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14.3.5  Input-Output  for  Numeric  Typos 


Integers: 

GET  reads  an  optional  minus  or  plus  sign  then  according  to  the  syntax  of  integer.  If  the  value 
obtained  is  outside  the  implemented  range  of  integer  numbers,  the  exception  OVERFLOW 
is  raised. 

PUT  expresses  the  ITEM  value  as  a decimal  integer,  with  no  underscores  and  no  leading  zeros 
(but  a single  0 for  the  value  zero)  and  a preceding  minus  sign  for  a negative  value;  this 
string  is  right  justified  in  the  field  width  and  padded  with  spaces. 

Floating  point  numbers: 

GET  reads  an  optional  plus  or  minus  sign  then  according  to  the  syntax  of  approximate  numbers. 
The  value  obtained  is  rounded  to  the  precision  FLOAT'DIGITS.  If  the  value  obtained  is  out- 
side the  implemented  range  for  type  FLOAT,  the  exception  OVERFLOW  is  raised. 

PUT  expresses  the  ITEM  value  as  the  nearest  approximate  number  with  one  digit  before  the 
decimal  point,  the  specified  number  of  digits  after  the  decimal  point,  and  an  exponent  part 
with  a sign  and  three  digits.  If  the  specified  number  of  decimals  is  not  positive,  then  the 
decimal  point  and  fractional  part  are  omitted.  If  the  specified  number  of  decimals  is  smaller 
than  that  authorized  by  the  precision,  rounding  is  performed. 

Fixed  point  numbers. 

Because  the  representation  of  a fixed  point  type  cannot  be  predetermined,  these  procedures  are 

contained  in  a generic  package. 

GET  reads  an  optional  plus  or  minus  sign  then  according  to  the  syntax  of  an  approximate  num- 
ber. The  value  obtained  is  rounded  to  the  appropriate  delta. 

PUT  expresses  the  ITEM  value  as  the  nearest  approximate  number  with  the  specified  number  of 
digits  after  the  decimal  point.  A default  is  provided  to  accommodate  the  delta.  If  the  speci- 
fied number  of  digits  is  smaller  than  that  needed  to  represent  delta,  then  rounding  is  per- 
formed. 


14.3.6  Input-Output  for  Boolean 


GET  reads  an  identifier  according  to  the  syntax  given  in  2.3,  with  no  distinction  between  upper 
and  lower  case  letters.  If  the  identifier  is  TRUE  or  FALSE,  then  the  boolean  value  is  given; 
otherwise  the  exception  INVALID_DATA  is  raised. 


PUT  expresses  the  ITEM  value  as  TRUE  or  FALSE  and  puts  these  letters  in  upper  case. 


14.3.7  Input-Output  for  Enumeration  Typos 

Because  each  enumeration  type  has  its  own  set  of  literals,  these  procedures  are  contained  in  a 
generic  package.  An  instantiation  must  specify  the  type. 

reads  an  identifier  (according  to  the  syntax  given  in  2.3,  with  no  distinction  between  upper 
and  lower  case  letters)  or  a character  literal  (according  to  the  syntax  of  2.5  for  a single 
character  in  double-quotes).  If  this  is  one  of  the  enumeration  literals  of  the  type  then  the 
enumeration  value  is  given;  otherwise  the  exception  INVALID_DATA  is  raised 

outputs  the  STEM  value  as  an  identifier  in  upper  case  or  as  a character  literal. 


GET 


HUT 


14.4  Specification  of  the  Package  TEXT  IO 

The  package  TEXTJO  contains  the  definition  of  all  the  text  input-output  primitives, 
package  TEXTJO  it 

age  CHARACTERJO  it  new  INPUT_OUTPUT(CHARACTER)- 
IN_EILE  it  new  CHARACTERJO. IN_FILE; 
type  OUT_FILE  it  new  CHARACTER  JO. OUT_  FILE: 

- Character  Input-Output 


procedure  GET  ( FILE  : in 
procedure  GET  ( ITEM  . out 
procedure  PUT  I FILE  : in 
procedure  PUT  ( ITEM  : in 

String  Input  Output 


IN_FILE;  ITEM  ; 
CHARACTER); 
OUT.FILE;  ITEM 
CHARACTER); 


out  CHARACTER). 
In  CHARACTER); 


procedure  GET  ( FILE  : in 
procedure  GET  ( ITEM  : out 
procedure  PUT  ( FILE  : in 
procedure  PUT  ( ITEM  : in 

— Integer  Input-Output 


IN_FILE;  ITEM 
STRING); 
OUT_FILE;  ITEM 
STRING): 


out  STRING); 

: In  STRING); 


DEFAULT_WIDTH  conetant  INTEGER  :=  0; 
procedure  GET  ( FILE  in  IN_FILE;  ITEM 

procedure  GET  ( ITEM  out  INTEGER)- 

procedure  PUT  ( FILE  : in  OUT_FILe’; 

ITEM  : In  INTEGER: 

WIDTH  : in  INTEGER 

procedure  PUT  ( ITEM  ; in  INTEGER- 


out  INTEGER); 


DEFAULT.WIDTH); 


WIDTH  in  INTEGER  :=  DEFAULT_WIDTH); 
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Floating  Point  Input  Output 


DEFAULT_FLOAT  .WIDTH 
DEFAULT.MANTISSA 
procedure  GET  ( FILE 
procedure  GET  ( ITEM 
procedure  PUT  ( FILE 
ITEM 
WIDTH 
FRACT 

procedure  PUT  I ITEM 
WIDTH 
FRACT 


constant  INTEGER  0: 

: constant  INTEGER  FLOAT  DIGITS  1 

In  IN-FILE:  ITEM  out  FLOAT) 
out  FLOAT); 

In  0UT_FILE; 

In  FLOAT; 

In  INTEGER  DEFAULT_FLOAT  WIDTH; 

In  INTEGER  DEFAULT.  MANTISSA); 

in  FLOAT: 

In  INTEGER  : DEFAULT_FLOAT_ WIDTH; 

In  INTEGER  DEFAULT  .MANTISSA) 


Fixed  Point  Input-Output  is  defined  as  a generic  package 


generic!  type  FIXED-TYPE; 

function  REP(X  FIXED.. TYPE)  return  STRING  Is  FIXED  TYPE  REP; 

function  VALIX  STRING)  return  FIXED. TYPE  Is  FIXED  TYPE  VAL 

DECIMALS  FIXED-TYPE  : FIXED  TYPE  DELTA) 
package  FIXED  JO  is 

constant  INTEGER  0 

constant  STRING  REP(DECIMAlS  INTEGERIDE CIMALS)) 
constant  INTEGER  DELTA.  REP  LENGTH  2; 

In  IN-FILE,  ITEM  out  FIXED-TYPE) 
out  FIXED-TYPE); 

In  OUT-FILE; 
in  FIXED-TYPE; 

In  INTEGER  DEFAULT  FIXED. WIDTH 

in  INTEGER  DEFAULT. DECIMALS) 

In  FIXED_TYPE; 

in  INTEGER  DEFAULT-FIXED  WIDTH: 

in  INTEGER  DEFAULT  DECIMALS) 


procedure 

procedure 


DEFAULT-FIXED_WIDTH 
DELTA-REP 
DEFAULT-DECIMALS 
procedure  GET  ( FILE 
GET  ( ITEM 
PUT  ( FILE 
ITEM 
WIDTH 
FRACT 

procedure  PUT  ( ITEM 
WIDTH 
FRACT 

end  FIXED-IO; 


Boolean  Input-Output 


DEFAULT-ENUM  WIDTH 

constant  INTEGER  0 

procedure  GET  ( FILE 

in 

IN-FILE  ITEM  out  BOOLEAN) 

procedure  GET  ( ITEM 

out 

BOOLEAN) 

procedure  PUT  ( FILE 

in 

OUT-FILE 

ITEM 

in 

BOOLEAN 

WIDTH 

in 

INTEGER  DEFAULT  ENUM  WIDTH) 

procedure  PUT  ( ITEM 

in 

BOOLEAN 

WIDTH 

in 

INTEGER  DEFAULT  ENUM  WIDTH) 
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generic!  type  ENUM  TYPE; 

function  REPIX  : ENUM. TYPE)  rotum  STRING  is  ENUM  .TYPE  REP; 
function  VAL(X  : STRING!  rotum  ENUM  TYPE  la  ENUM  TYPE'VALI 
package  ENUM _IO  it 


procoduro 

GET  ( FILE 

in 

IN.FILE,  ITEM  out  ENUM  TYPE); 

procoduro 

GET  ( ITEM 

: out 

ENUM.TYPE); 

procedure 

PUT  ( FILE 

: in 

OUT_FILE; 

ITEM 

in 

ENUM.TYPE; 

WIDTH 

in 

INTEGER  DEFAULT.ENUM  WIDTH); 

procedure 

PUT  I ITEM 

: in 

ENUM_TYPE; 

WIDTH 

in 

INTEGER  DEFAULT  .ENUM  WIDTH); 

and  ENUM  10: 


- Layout  primitives 

function  LINEIFILE  in  IN_FILE>  rotum  NATURAL 

function  LINEIFILE  in  OUT.FILE)  rotum  NATURAL: 

function  COLIFILE  : in  IN.FILE)  rotum  NATURAL; 

function  COLIFILE  . in  OUT_FILE)  rotum  NATURAL; 

procoduro  SET  LINEIFILE  : in  IN.FILE;  TO  : in  NATURAL) 

procedure  SET_LINE(FILE  : in  OUT. FILE;  TO  : in  NATURAL); 

procoduro  SET.COLIFILE  ; in  IN.FILE;  TO  : in  NATURAL); 

procoduro  SET.COLIFILE  : in  OUT_FILE;  TO  ; in  NATURAL): 

procoduro  SET_LINE_LENGTH(FILE  in  IN_FILE;  N : in  NATURAL); 
procoduro  SET.LINE.LENGTHIFILE  : in  OUT.FILE;  N : In  NATURAL); 

NEWLINE  constant  STRING  : implementation  defined-. 

Standard  input  and  output  file  manipulation 

function  STANDARD_INPUT  rotum  IN.FILE; 
function  STANDARD_OUTPUT  return  OUT.FILE; 

procedure  SETJNPUT  (FILE  : in  IN.FILE); 
procoduro  SET. OUTPUT  (FILE  In  OUT.FILE); 

Exceptions 


FILE.NAME.ERROR 
FILE.USE  ERROR 
FILE.OPEN.  ERROR 
INVALID  DATA 
MALFUNCTION 
END_OF.  FILE 
INVALID  LAYOUT 


and  TEXT.  10; 


exception; 
exception ; 
exception 
exception; 
exception 
exception 
exception; 


J 
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14.5  Example  of  Taxt  Input-Output 


1 


1 


The  following  example  shows  the  use  of  the  text  input-output  primitives  in  a dialogue  with  a user 
at  a terminal.  The  user  is  asked  to  select  a color,  and  the  program  output  in  response  is  the  nun.oer 
of  items  of  the  color  available  in  stock.  The  default  input  and  output  files  are  used. 

type  COLOR  Is  (WHITE.  RED.  ORANGE.  YELLOW.  GREEN.  BLUE.  BROWN); 

TARGET  : array  (WHITE  ..  BROWN)  of  INTEGER  :=  (20  17.  43.  10.  28  173  87): 

package  COLORJO  It  new  ENUMJO(COLOR); 

procedure  DIALOGUE  is 
use  COLORJO; 

CHOICE:  COLOR: 

procedure  READLN  is 
CH  : CHARACTER; 
begin 
loop 

GET(CH); 

exit  when  CH  - LF; 
end  loop: 
end; 

procedure  ENTER.COLOR  return  COLOR  is 
CHOICE  : COLOR; 

begin 

loop 

begin 

PUT( "Color  selected:  "); 

GET(CHOICE); 

READLN; 
return  CHOICE; 
exception 

when  INVALID_DATA  => 

READLN; 

PUT("lnvalid  color,  try  again."); 

end; 

end  loop; 
end; 

begin  — body  of  DIALOGUE 
CHOICE  :=  ENTER_C0L0R; 

PUT(NEWLINE); 

PUT(CHOICE);  PUTCitems  available:"); 

SET_COL(STAN DAR D_0UTPUT,  25); 

PUT(TARGETICHOICE).  WIDTH  :=  5); 

PUTC;"  & NEWLINE); 
end  DIALOGUE; 

Example  of  an  interaction  (characters  typed  by  the  user  are  italicized): 

Color  selected:  black 

Invalid  color,  try  again.  Color  selected:  blue 
BLUE  items  available:  173; 


i 

i 

■ 
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14.S  Low  UmI  Input-Output 


A low  level  input-output  operation  is  an  operation  acting  on  a physical  device.  Such  an  operation  is 
handled  by  using  one  of  the  (overloaded)  predefined  procedures  SEND_CONTROL  and  RECEIVE_- 
CONTROL. 

A procedure  SEND_CONTROl  may  be  used  to  send  control  information  to  a physical  device.  A 
procedure  RECEIVE_CONTROL  may  be  used  to  monitor  the  execution  of  an  input-output  opera- 
tion by  requesting  information  from  the  physical  device. 

Such  procedures  are  declared  in  the  standard  package  LOW_LEVEL_IO  and  have  two  parameters 
identifying  the  device  and  the  data.  However,  the  kinds  and  formats  of  the  control  information  will 
depend  on  the  physical  characteristics  of  the  machine  and  the  device.  Hence  the  types  of  the 
parameters  are  implementation  defined.  Overloaded  definitions  of  these  procedures  should  be 
provided  for  the  supported  devices. 

The  visible  part  of  the  package  defining  these  procedures  is  outlined  as  follows: 
package  LOW_LEVELJO  is 

--  declarations  of  the  possible  types  for  DEVICE  and  DATA 
— declarations  of  overloaded  procedures  for  these  types: 

procedure  SEND_CONTROL  (DEVICE  : device  type:  DATA  : in  out  data,  type); 
procedure  RECEIVE_CONTROL  (DEVICE  : device  type ; DATA  : in  out  data,  type); 

end; 

The  bodies  of  the  procedures  SEND_CONTROL  and  RECEIVE_CONTROL  for  various  devices  can 

be  supplied  in  the  body  of  the  package  LOW_LEVEI 10.  These  procedure  bodies  may  be  written 

with  code  statements. 
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A.  Predefined  Language  Attributes 


The  following  attributes  are  predefined  in  the  language  and  are  denoted  by  the  notation  described 
in  section  4.1,  wher,  the  name  of  the  entity  is  followed  by  an  apostrophe  and  the  attribute  iden- 
tifier. 


Attributes  of  any  object  or  subprogram 

ADDRESS  X’ADDRESS  returns  an  integer  corresponding  to  the  location  of  the 

first  storage  cell  of  X,  which  is  given  as  an  index  in  a linear  memory. 


i 


Attributes  of  any  type  or  subtype  (or  objects  thereof) 

SIZE  Gives  the  number  of  bits  used  to  implement  objects  of  the  type. 


Attributes  of  any  scalar  type  or  subtype 

FIRST  TFIRST  returns  the  minimum  value  in  the  range  of  T. 

LAST  TLAST  returns  the  maximum  value  in  the  range  of  T. 

REP(X)  X being  an  object,  T'REP(X)  returns  the  string  representation  of  the 

value  of  X.  The  string  contains  the  minimum  number  of  characters 
needed,  i.e.: 

• For  a number,  only  significant  digits  are  given,  and  the  number  of 
decimal  digits  is  the  smallest  number  required  to  express  the 
mantissa  within  the  declared  accuracy.  A floating  point  number  is 
represented  in  scientific  notation  with  one  digit  before  the 
decimal  point,  and  a signed  three  digit  exponent.  A fixed  point 
number  is  represented  in  fixed  point  notation.  All  numbers  are 
expressed  in  base  10. 

• Fo’  enumeration  literals,  identifiers  are  represented  in  upper- 
case, without  any  extra  space.  Character  values  are  represented 
surrounded  by  double  quotes 

VAL(X)  X being  a string,  T'VAL(X)  returns  the  value  of  type  T whose  external 

representation  is  given  by  the  string  X.  If  no  interpretation  of  X can  be 
given  within  T,  the  RANGE_ERROR  exception  is  raised. 


Attributes  of  any  real  type  or  subtype 

BITS  Returns  an  integer  indicating  the  minimum  number  of  bits  needed  to  repre- 

sent the  mantissa  of  the  type  or  subtype. 


i 


: 


l 


! 
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Attr/Outes  of  any  discrete  type  or  subtype  T 


PREDiX) 

Returns  the  value  preceding  X in  T.  The  exception  RANGE_ERROR  is 
raised  if  X - T FIRST 

SUCC(X) 

Returns  the  value  following  X in  T The  exception  RANGE_ERROR  is 
raised  if  X "I  LAST 

ORDIX) 

Returns  an  integer  which  is  the  ordinal  position  of  X in  the  type  or 
subtype  T Note  that  T'ORD(T'FIRST)  = 1.  and  that  ORD  is  indepen- 
dent of  any  representation  specification:  T ORDIT  SUCCIX))  - 
T ORD(X)  + 1. 

VAL(I) 

1 being  an  integer,  T VAL(I)  returns  the  enumeration  value  occupying 
the  l-th  position  in  T.  The  exception  RANGE_ERROR  is  raised  if  1 is 
not  in  the  range  T’ORD(T'FIRST)  T'ORDIT  LAST).  For  any  enumera- 
tion value  X of  type  T T'VAL(T'ORD(X)l  - X. 

Attributes  of  any  numeric 

type  or  subtype 

RADIX 

Returns  an  integer  giving  the  actual  radix  (base)  used  to  represent 
values  of  the  type. 

Attributes  of  any  fixed  point  type  or  subtype  T 

DELTA 

Returns  a fixed  point  number  indicating  the  value  of  the  delta  sped 
fied  in  the  type  declaration. 

SMALL 

Returns  a fixed  point  number  indicating  the  closest  (positive  or  negati- 
ve) power  of  2 immediately  inferior  to  the  delta  For  example,  if  T DEL- 
TA -.  0.005.  then  TSMALL  is  0.00390625  (1/256). 

LARGE 

Returns  a fixed  point  number  indicating  the  largest  permissible  value 
that  can  be  expressed  in  the  binary  representation  of  T with  a delta  of 
TSMALL:  if  T is  declared  "delta  0.01  range  -100.0  100  0'  then 

T' LARGE  = 256  - 1/128  = 255.9921875 

Attributes  of  any  floating  point  type  or  subtype 

DIGITS 

Returns  an  integer  indicating  the  number  of  decimal  digits  specified  in 
the  type  or  subtype  declatation 

LARGE 

Returns  the  largest  positive  value  that  can  be  expressed  in  the  repre 
sentation  within  the  constraints  of  the  precision  of  T 

SMALL 

Returns  the  smallest  positive  value  that  can  be  expressed  in  the  repre- 
sentation within  the  constraints  of  the  precision  of  T. 

EXPONENT_MIN 

The  minimum  exponent  (as  an  integer)  possible  in  the  representation 
used  for  values  of  the  type. 

EXPONENT_MAX 

The  maximum  exponent  (as  an  integer)  possible  in  the  representation 
used  for  values  of  the  type 

Attributes  of  any  array  object  anc'  of  any  array  type  with  specified  bounds 

FIRST  Returns  a value  in  the  type  of  the  first  index,  which  is  the  lower  bound 

of  that  index. 

FIRST(i)  Same  as  FIRST,  for  the  i-th  index 

LAST  Upper  bound  of  the  first  index 

LAST(i)  Same  as  LAST,  for  the  i-th  index. 

LENGTH  Number  of  elements  of  the  first  dimension 

LENGTH(i)  Same  as  LENGTH,  for  the  i-th  dimension. 


Attributes  of  any  access  type  (or  object  thereof) 

ACCESS_SIZE  Returns  an  integer  giving  the  size  in  bits  required  for  an  object  of  the 

access  type  (whereas  SIZE  will  give  the  size  of  the  value  denoted  by 
such  object). 


Attributes  of  any  record  component 

FIRST_BIT  Gives  the  bit  position  (as  an  integer)  of  the  first  bit  of  the  component 

in  the  first  storage  unit  used  for  the  component.  The  first  bit  in  the 
storage  unit  has  the  position  0. 

LAST_BIT  Bit  position  of  the  last  bit  of  the  component  from  the  beginning  of  the 

first  storage  unit  used  for  the  component. 

POSITION  Gives  the  position  (in  storage  units)  of  the  first  storage  unit  of  the 

component  relative  to  the  beginning  of  the  record.  Position  of  the  first 
component  is  0. 

Attributes  of  any  task 

ACTIVE  True  if  the  corresponding  task  has  been  initiated,  and  is  not  yet  ter 

minatad. 

CLOCK  Returns  a value  of  type  TIME  which  is  the  cumulative  processing  time 

of  the  task  since  its  last  initiation.  Can  be  used  only  in  the  task  body 

INDEX  (for  a task  family)  Returns  the  index  (of  the  type  of  the  family  index)  of 

the  current  member  of  the  family.  Can  be  used  only  in  the  task  body. 

PRIORITY  Returns  a value  of  the  predefined  type  PRIORITY,  which  is  the  current 

priority  of  the  task.  Can  be  used  only  in  the  task  body. 

| 


W 
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Attributes  of  any  entry 


COUNT 


Indicates  the  number  of  tasks  currently  awaiting  a rendezvous  with 
the  entry  Can  be  used  only  within  the  body  of  the  task  containing  the 
entry  declaration. 


Attributes  of  SYSTEM 


CLOCK 

Current  time  (of  type  TIME)  indicated  by  the  real  time  clock  of  the 
system. 

MEMORY_SIZE 

Number  of  storage-units  available  to  tl.e  program. 

NAME 

Returns  a literal  of  an  implementation-defined  enumeration  type, 
identifying  the  target  system. 

STORAGE_UNIT 

Number  of  bits  in  a storage  unit. 

MAX_PRIORITY 

The  maximum  priority  level  for  tasks  on  the  system  (of  the  predefined 
subtype  PRIORITY). 

MIN_PRIORITY 

The  minimum  priority  level. 

MAX_INT 

The  maximum  integer  value  supported  by  the  machine 

MIN.INT 

The  minimum  integer  value  supported  by  the  machine. 

Translator  options 

OPTION'SPACE 

True  if  major  optimization  criterion  is  space  efficiency. 

OPTIONTIME 

True  if  major  optimization  criterion  is  time  efficiency. 
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B.  Predefined  Language  Pragma* 


Pragma  Name  Meaning 


i 


CREATION  The  identifier  STATIC  or  DYNAMIC  must  be  given  as  a parameter.  The 

pragma  must  appear  in  the  visible  part  of  a task  module.  It  specifies 
whetner  storage  for  the  task  is  to  be  allocated  statically  or  dynamically. 

ENVIRONMENT  Takes  a list  of  module  names  as  arguments.  The  pragma  must  appear 
before  a compilation  unit.  It  specifies  other  visible  modules  to  be  included 
in  the  standard  environment  for  all  compilation  units  in  the  program  library. 

INCLUDE  Takes  a string  as  argument,  which  is  the  name  of  a text  file.  The  pragma 

can  appear  in  a declarative  part  or  sequence  of  statements.  It  specifies  that 
the  text  file  is  to  be  included  where  the  pragma  is  given 

INLINE  No  arguments.  The  pragma  must  appear  in  the  declarative  part  of  a sub- 

program body.  It  specifies  that  the  subprogram  body  should  be  expanded 
in  line  at  each  call. 

INTERFACE  Takes  an  identifier  as  argument,  indicating  that  the  body  of  a subprogram 

is  written  in  another  language,  whose  linkage  convention  is  to  be  observed. 
The  list  of  possible  languages  is  implementation  defined. 

LIST  The  argument  is  either  ON  or  OFF.  The  pragma  can  appear  in  a declarative 

part  or  sequence  of  statements.  It  specifies  that  listing  of  the  program  unit 
is  to  be  continued  or  suspended  until  a LIST  pragma  is  given  with  the 
opposite  argument. 

MEMORY_SIZE  Takes  an  integer  argument  indicating  the  number  of  storage  units  available 

in  memory. 

OPTIMIZE  The  argument  is  TIME  or  SPACE.  The  pragma  can  appear  before  a com- 

pilation unit  or  within  a declarative  part  or  sequence  of  statements.  It 
specifies  whether  time  or  space  is  the  primary  optimization  criterion.  The 
effect  of  the  pragma  holds  until  the  end  of  the  unit,  unless  another 
OPTIMIZE  pragma  overriding  it  is  given. 

PAGE  Indicates  that  the  listing  should  start  on  a new  page. 

STORAGE_UNIT  Takes  an  integer  argument  indicating  the  number  of  bits  to  be  used  for 

each  storage  unit. 

SUPPRESS  Exception  names  are  given  as  arguments.  The  pragma  must  appear  in  the 

declarative  part  of  a program  unit.  It  specifies  that  within  the  unit  no  run- 
time checks  need  be  provided  for  the  named  exceptions. 

SYSTEM  An  identifier  is  given  as  argument,  and  interpreted  as  the  name  of  the 

target  system  of  the  program.  The  list  of  possible  names  is  implementation 
defined. 
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This  appendix  outlines  a definition  of  the  predefined  identifiers  in  the  language.  The  definition  is 
given  in  the  form  of  a package  module  called  STANDARD,  which  is  implicitly  inherited  by  all 
program  units  (see  8.6). 

The  types  and  other  facilities  given  in  STANDARD  are  deliberately  minimal,  since  further 
packages,  for  instance,  for  complex  arithmetic,  can  be  expressed  in  the  language  itself.  An 
implementation  may,  of  course,  make  such  packages  a part  of  the  standard  environment.  Further- 
more, the  predefined  functions,  operators,  and  procedures  can  be  implemented  in  special  ways 
that  are  particularly  efficient  on  a given  machine.  For  this  reason,  the  corresponding  package  body 
is  not  shown. 

Not  all  the  predefined  entities  can  be  completely  described  in  the  language  itself.  For  instance, 
although  the  enumeration  type  BOOLEAN  can  be  written  showing  the  two  literals  FALSE  and 
TRUE,  the  relationship  of  BOOLEAN  to  conditions  cannot  be  expressed  in  the  language.  In  conse- 
quence, the  text  of  the  pacxage  given  below  does  not  give  the  complete  semantics  of  the  entities 
defined. 


package  STANDARD  is 

type  BOOLEAN  is  (FALSE,  TRUE); 

function  "not"  (X  : BOOLEAN)  return  BOOLEAN: 

function  "and"  (X,Y  : BOOLEAN)  return  BOOLEAN 

function  "or"  |X,Y  : BOOLEAN)  return  BOOLEAN 

function  "xor"  (X,Y  : BOOLEAN)  return  BOOLEAN 


type  SHORT_INTEGER  is  range  implementation  defined', 

type  INTEGER  is  range  implementation  defined: 

type  LONG_INTEGER  is  range  implementation  defined: 

function  "+"  (X  : INTEGER)  return  INTEGER; 

function  "-"  (X  : INTEGER)  return  INTEGER; 

function  ABS  (X  : INTEGER)  return  INTEGER; 

function  "+"  (X.Y  : INTEGER)  return  INTEGER; 

function  "-"  (X.Y  : INTEGER)  return  INTEGER; 

function  "*"  (X.Y  : INTEGER)  return  INTEGER; 

function  7"  (X.Y  : INTEGER)  return  INTEGER; 

function  "mod"  (X,Y  : INTEGER)  return  INTEGER; 

function  "**"  (X  : INTEGER;  Y : INTEGER  range  0 ..  INTEGER  LAST)  return  INTEGER; 
- Similarly  for  SHORTJNTEGER  and  LONGJNTEGER 


b 


type  SHORT_FLOAT  it  digits  implementation 

type  FLOAT  it  digits  implementation 

type  LONG_FLOAi  it  digits  implementation 

function  " + " (X  : TLOAT)  return  FLOAT: 

function  (X  : FLOAT)  return  FLOAT: 

function  ABS  (X  : FLOAT)  return  FLOAT: 

function  " + “ (X.Y  : FLOAT)  return  FLOAT: 

function  (X.Y  FLOAT)  return  FLOAT: 

function  (X.Y  : FLOAT)  return  FLOAT 

function  T (X.Y  FLOAT)  return  FLOAT 

function  (X  : FLOAT:  Y INTEGER)  return  FLOAT: 

— Similarly  for  SHORT_FLOAT  and  LONG..FLOAT 

The  following  characters  comprise  the  standard  ASCII  character  set. 


type  CHARACTER  it 


NUL. 

SOH. 

STX. 

ETX 

EOT 

ENQ. 

ACK, 

BEL. 

BS 

HT. 

LF 

VT 

FF. 

CR. 

SO. 

SI. 

DLE. 

DC1 , 

DC2, 

DC3. 

DC4 

NAK, 

SYN, 

ETB 

CAN 

EM. 

SUB 

ESC 

FS 

GS. 

RS. 

US. 

**  " 

T# 

•**•**" 

. 

“S*. 

•)’. 

+• 

M •» 

**  ** 

T. 

O' 

”i', 

"2" 

"3". 

"4", 

"5". 

, ■6". 

"7". 

“8". 

"9", 

" = "# 

■>*. 

"A" 

B\ 

*C*. 

"D", 

"E'\ 

"F". 

"G", 

"H*. 

"1". 

"K" 

"L". 

”M". 

"N". 

’O'. 

"P". 

"O'. 

'R“. 

"S'. 

"T", 

"U", 

"V". 

"W". 

'X'. 

' Y' 

"Z". 

T. 

Y. 

*1" 

1 . 

, 

'a". 

"b". 

"c*\ 

"d". 

"e", 

*r. 

9”. 

"h", 

T\ 

Y. 

"k". 

*r. 

"n", 

"o'*. 

"P". 

"q'. 

"r"# 

"s'\ 

"t\ 

"iT. 

~vr 

"x", 

V . 

"z. 

T. 

T. 

T. 

DELI: 

Enumeration  literals  for  characters  not  in  the  basic  language  character  set 


EXCLAM 

constant  CHARACTER 

= T; 

DOLLAR 

constant  CHARACTER 

= "S' 

QUESTION 

constant  CHARACTER 

= 

AT_SIGN 

constant  CHARACTER 

- "(o  ' 

LBRACKET 

constant  CHARACTER 

= T: 

BACK_SLASH 

constant  CHARACTER 

= Y: 

R_BRACKET 

constant  CHARACTER 

= T; 

CIRCUMFLEX 

constant  CHARACTER 

_ — . 

GRAVE 

constant  CHARACTER 

LC_A 

constant  CHARACTER 

= "a"; 

LC_B 

constant  CHARAl  i ER 

= "b“; 

LC_Z 

constant  CHARACTER 

1 BRACE 

constant  CHARACTER 

= T; 

R_  BRACE 

constant  CHARACTER 

= T; 

TILDE 

constant  CHARACTER 

= m‘~m: 

I 


defined  rengo  implementation  detmed, 
defined  renge  implementation  defined : 
defined  range  implementation  defined. 


subtype  NATURAL  la  INTEGER  range  1 . INTEGER  LAST 
type  STRING  la  array  (NATURAL)  of  CHARACTER 


type  TIME  la  dlpita  implementation  defined  range  implementation  defined 
SECONDS  : conatant  TIME  : implementation  defined. 


SYSTEM  predefined  name 

OPTION  : predefined  name 

subtype  PRIORITY  Is  INTEGER  range  implementation  defined 
procedure  SET  PRIORITY(P  : PRIORITY); 


Alphabetical  list  of  exceptions 

ACCESS  ERROR  : exception 

ASSERT..ERROR  : exception. 

DISCRIMINANT  ERROR  exception; 

DIVIDE.  ERROR  exception; 

FAILURE  axoeption; 

INITIATE_ERROR  : exception: 

NO„VALUE„ERROR  axoeption 

OVERFLOW  ; exception: 

OVERLAP.ERROR  exception; 

RANGE„ERROR  : exception 

SELECT  ERROR  : exception; 

STORAGE. OVER  FLOW  exception 

TASKING. .ERROR  : axoeption; 

UNDERFLOW  : exception; 

generic  task  SEMAPHORE  Is 
entry  P; 
entry  V: 
and. 

generic  teak  SIGNAL  la 
entry  SEND, 
entry  WAIT; 
end: 

for  CHARACTER  use  128  ASCII  character  set  without  holes 
(0.  I.  2.  3.  4.  5.  6.  1.  8 126  127). 

for  STRING  use  packing: 

end  STANDARD; 


O.  Glossary 


Access  type  An  access  type  is  a type  whose 
objects  are  allocated  dynamically  during  program 
execution.  An  access  value  designates  a 
dynamically  allocated  object. 

Aggregate  An  aggregate  is  the  written  form 
denoting  a value  of  a composite  type.  An  array 
aggregate  denotes  a value  for  an  array;  a record 
aggregate  denotes  a value  for  a record. 

Allocator  An  allocator  creates  a new  dynamically 
allocated  object  and  returns  an  access  value 
designating  the  object. 

Attribute  An  attribute  is  a characteristic  of  a 
named  entity.  A predefined  attribute  relates  to 
the  program  < ntity,  and  is  obtained  by  using  one 
of  the  predefined  attribute  identifiers  in  the 
language.  A user  defined  attribute  exists  only  for 
types,  and  denotes  a user  defined  subprogram 
for  the  type. 

Body  A body  is  a program  unit  defining  the 
execution  of  a subprogram  or  module.  A body 
stub  is  a replacement  for  a body  that  is  compiled 
separately. 

Compilation  unit  A compilation  unit  is  a 
restricted  program  unit  that  is  presented  for  com- 
pilation as  a separate  text.  It  may  be  a sub- 
program body,  a module  specification,  or  a 
module  body. 

Component  A component  denotes  a part  of  a 
composite  object  or  a nameable  entity  declared 
in  a program  unit.  An  indexed  component  is  a 
name  containing  expressions  denoting  indices. 
An  indexed  component  can  denote  either  a com- 
ponent of  an  array,  a task  in  a task  family,  or  an 
entry  in  an  entry  family.  A selected  component  is 
a name  whose  prefix  names  another  declared 
entity  and  whose  suffix  denotes  a component  of 
the  entity.  A selected  component  can  denote 
either  a component  of  a record,  an  entity 
declared  in  another  program  unit,  or  a user 
defined  type  attribute. 


Constraint  A constraint  is  a restriction  on  the  set 
of  possible  values  of  a type  A range  constraint 
specifies  the  lower  and  upper  bounds  for  the 
values  of  a scalar  type.  An  accuracy  constraint 
specifies  the  relative  or  absolute  bounds  on 
errors  for  a real  type.  An  index  constraint 
specifies  the  lower  and  upper  bounds  of  an  array 
index  A discriminant  constraint  specifies  a par 
ticufar  variant  for  a record  type. 

Declarative  part  A declarative  part  is  a sequence 
of  declarations  and  related  information  such  as 
subprogram  bodies  and  representation  specifica- 
tions that  apply  over  a region  of  program  text. 

Derived  type  A derived  type  is  a type  whose 
operations  and  values  are  taken  from  an  existing 
type. 

Discrete  type  The  discrete  types  are  the 
enumeration  types  and  integer  types.  Discrete 
types  may  be  used  for  indexing  and  iteration  over 
loops 

Discriminant  A discriminant  is  a constant  com 
ponent  of  a record.  The  value  of  the  discriminant 
determines  the  particular  variant  of  a given 
record  value  or  the  size  of  an  array  component 

Elaboration  Elaboration  is  the  process  by  which 
a declaration  achieves  its  effect.  For  example  it 
can  associate  a name  with  a program  entity  or 
initialize  a newly  declared  variable. 

Entry  An  entry  is  used  for  communication 
between  tasks.  Externally  an  entry  is  called  just 
as  a subprogram  is  called;  its  internal  behaviot  is 
specified  by  one  or  more  accept  statements 
specifying  the  actions  to  be  performed  when  the 
entry  is  called. 

Exception  An  exception  is  an  event  that  causes 
suspension  of  normal  program  execution.  Bring- 
ing an  exception  to  attention  is  called  raising  the 
exception.  An  exception  handler  is  a piece  of 
program  text  specifying  a response  to  the  excep- 
tion. Execution  of  such  a program  text  is  called 
handling  the  exception. 
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Generic  program  unit  A generic  program  unit  is  a 
subprogram  or  module  specified  with  a generic 
clause.  A generic  clause  contains  the  declaration 
of  generic  parameters.  A generic  program  unit 
may  be  thought  of  as  a possibly  parameterized 
model  of  program  units  Instances  tie.  filled-in 
copies)  of  the  model  can  be  obtained  by  generic 
instantiation  Such  instantiated  program  units 
define  subprograms  and  modules  that  can  be 
used  directly  in  a program 

Lexical  unit  A lexical  unit  is  one  of  the  basic  syn 
tactic  elements  comprising  a program.  A lexical 
unit  is  either  an  identifier,  number  string  or 
delimiter 

Literal  A literal  denotes  an  explicit  value  of  a 
given  type  for  example  a number  or  a character 
string. 

Module  A module  is  a program  unit  specifying  a 
group  of  logically  related  entities  The  visible  part 
of  the  module  specification  defines  the  informa 
tion  that  another  program  unit  is  able  to  know 
about  the  module.  The  private  part  of  the  module 
specification  defines  the  physical  characteristics 
of  the  information  specified  in  the  visible  part.  A 
module  body  contains  the  bodies  of  specified 
subprograms  and  local  declarative  information, 
as  well  as  statements  to  be  executed  when  the 
module  body  is  elaborated  (for  a package 
module)  or  initiated  (for  a task  module) 

Object  An  object  is  a variable  or  a constant  An 
object  can  denote  any  kind  of  data  element, 
whether  a scalar  value,  a composite  value  or  a 
value  in  an  access  type 

Overloading  Overloading  is  the  property  of 
literals  identifiers  and  operators  that  can  have 
several  alternative  meanings  within  the  same 
scope  For  example  an  overloaded  enumeration 
literal  is  a literal  appearing  in  two  or  more 
enumeration  types:  an  overloaded  subprogram 
is  a subprogram  whose  name  can  denote  one  of 
several  subprogram  bodies,  depending  upon  the 
kirtd  of  its  parameters  and  returned  value 

Package  A package  is  a module  specifying  a col 
lection  of  related  entities  such  as  constants, 
variables,  types  and  subprograms 


Parameter  A parameter  is  one  of  the  named 
entities  associated  with  a subpiogiam.  entry  or 
generic  program  unit  A formal  parameter  is  an 
identifier  used  to  denote  the  named  entity  in  the 
unit  body  An  actual  parameter  is  the  particular 
entity  associated  with  the  corresponding  formal 
parameter  in  a subprogram  call,  entry  call,  01 
generic  instantiation.  A parameter  mode 
specifies  whether  the  parameter  is  used  for  input, 
output  or  input  output  of  data.  A positional 
parameter  is  an  actual  parameter  passed  in 
positional  order  A named  parameter  is  an  actual 
parameter  passed  by  naming  the  corresponding 
formal  parameter. 

Pragma  A pragma  is  an  instruction  to  the  com- 
piler and  may  be  language  defined  or  implemen 
t<i  tion  defined. 

Private  type  A private  type  is  a type  where  the 
set  of  possible  values  is  clearly  defined,  but  not 
known  to  the  users  of  such  types  A private  type 
is  only  known  by  the  set  of  operations  applicable 
to  its  values  A private  type  and  i»s  applicable 
operations  are  defined  in  the  visible  part  of  a 
module.  Assignment  and  the  predefined  com- 
parison for  equality  or  inequality  are  allowed  for 
all  private  types  unless  the  private  type  is 
marked  as  restricted. 

Qualified  expression  A qualified  expression  is  an 
expression  qualified  by  the  name  of  a type  or 
subtype.  It  can  be  used  to  state  the  type  or  sub 
type  of  an  expression,  for  example  for  an 
overloaded  litoral  It  can  also  be  used  to  specify  a 
conversion  to  the  named  type  when  the  conver 
sion  is  permitted 

Range  A range  is  a contiguous  set  of  values  of  a 
scalar  type  A range  is  specified  by  giving  the 
:ower  and  upper  bounds  for  the  values 

Rendezvous  A rendezvous  is  the  interaction  that 
occurs  between  two  parallel  tasks  when  one  task 
has  called  an  entry  of  the  other  task,  and  a cor- 
responding accept  statement  is  being  executed 
by  the  other  task.  During  a rendezvous,  informa- 
tion can  be  exchanged  by  means  of  parameters 
associated  with  the  entry. 
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Representation  specification  Representation 
specifications  specify  the  mapping  between  data 
types  and  features  of  the  underlying  machine 
that  execute  a program.  In  some  cases,  they 
completely  specify  the  mapping,  in  other  cases 
they  provide  criteria  for  choosing  a mapping. 

Restricted  program  unit  A restricted  program 
unit  is  a subprogram  or  module  with  a visibility 
restriction.  The  visibility  restriction  limits  the 
visibility  of  outer  units. 

Restricted  type  A restricted  type  is  a private  type 
for  which  assignment  and  the  predefined  com- 
parison for  equality  are  not  available. 

Scalar  type  A scalar  type  is  a type  whose  values 
have  no  components.  Scalar  types  comprise  dis- 
crete types  (i.e  enumeration  and  integer  types) 
and  real  types. 

Scope  The  scope  of  a declaration  is  the  region  of 
text  over  which  the  declaration  has  an  effect. 


Static  expression  A static  expression  is  one 
whose  value  does  not  depend  on  any  dynamical- 
ly computed  values  of  variables. 

Subprogram  A subprogram  is  an  executable 
program  unit,  possibly  with  parameters  specify- 
ing its  calling  conventions.  A subprogram 
declaration  specifies  the  name  of  a subprogram 
and  its  calling  conventions.  A subprogram  body 
specifies  its  execution. 


Subtype  A subtype  of  a type  is  obtained  from  the 
type  by  constraining  the  set  of  possible  values  of 
the  type.  The  operations  over  a subtype  are  the 
same  as  those  of  the  type  from  which  the  sub- 
type  is  obtained 

Task  A task  is  a module  that  may  operate  in 
parallel  with  other  task  modules  A task  family 
defines  a number  of  tasks  with  identical  proper 
ties,  each  denoted  by  an  index. 

Type  A type  characterizes  a set  of  values  and  a 
set  of  operations  applicable  to  those  values.  A 
type  attribute  denotes  an  operation  for  the  type 
or  a property  of  its  values.  A type  definition  is  a 
language  construct  introducing  a type.  A type 
declaration  associates  a name  with  a type 
introduced  by  a type  definition. 

Use  clause  A use  clause  opens  the  visibility  to 
declarations  given  in  the  visible  parts  of  given 
modules. 

Variant  A variant  part  specifies  alternative  record 
components  in  a record  type.  Each  variant 
defines  the  components  for  a corresponding 
value  of  the  record  s discriminant. 

Visibility  At  a given  point  in  a program  text,  the 
declaration  of  an  entity  with  a certain  identifier  is 
said  to  be  visible  if  the  entity  is  an  acceptable 
meaning  for  an  occurrence  of  the  identifier.  By 
convention  an  identifier  is  said  to  be  visible  if  its 
declaration  is  visible.  A visibility  restriction  is  a 
restriction  on  a program  unit  that  limits  its 
visibility  of  outer  units. 
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E.  Syntax  Summary 


2 3 

identifier 

letter  llunderscorel  letter_or_diflit| 
letter  or  digit  letter  | digit 
letter  .:=  upper  case-letter  | lower _caseJettt" 

2 4 

number  ::  Integer  .number  | approximate,  number 
integer  .number  integer  | basedjnteger 
integer  ::  digit  llunderscorel  digitl 
based  .integer 

base  # extended-digit  llunderscorel  extended-digit) 

base  integer 

extended-digit  ::=  digit  | letter 

approximate-number 

integer.integer  |E  exponentl 
I integer  E exponent 

exponent  | + | integer  | - integer 
2.5 

character  string  " Icharacterl  " 

2 7 

pragma  ::<= 

pragma  identifier  llargument  |.  argument|)|; 
argument  ::  identifier  | character  string  j number 

3 1 

declaration 

object  .declaration  | type  declaration 

I subtype. declaration  j private.type. declaration 

I ubprogram  .declaration  j module-declaration 
I entry-declaration  j exception-declaration 

I renaming_declaration 

32 

object-declaration 

identifier. list  : | constant  I type  |:»  expression!; 
identifierjist  identifier  |.  identifier! 


3 3 

type  type.definition  | type.mark  Iconstraintl 
type,  definition 

enumeration  type  definition  | integer. type.detinitiun 
I real,  type.definition  | array. type  definition 

I recoro.type  definition  | access,  type,  definition 

I derived,  type  definition 


type.mark  type  name  | subtype _i iame 
constraint 

range.constraint  | accuracy.constraint 
I index,  constraint  | discriminant  constraint 

type,  declaration  :: 

type  identifier  lis  type  .definition!; 

subtype.declaration 

subtype  identifier  is  type.mark  Iconstraintl; 


3.4 

derived. type. definition  ::  new  type.mark  Iconstraintl 


3 5 

range.constraint  ::  range  range 

range  simple  expression  simple. expression 


3 5.1 

enumeration  .type  definition  :: 

(enumeration-literal  I,  enumeration..literal|l 

enumeration  literal  : identifier  | character-literal 


3 54 

integer  type  definition  ::  range  . onstraint 


3.5  5 

real. type  definition  ::  accuracy.constraint 

accuiacy.constraint  :: 

digits  simple  expression  |range.constraint| 
| delta  simple  expression  (range  constraint! 


E-1 


r 


3.6 

erray_type_definition 

array  (index  (,  indexl)  of  type_mark  |constraint| 
index  ::=  discrete_range  | type_mark 
discrete_range  ::=  |type_mark  range)  range 
index_constraint  ::=  (discrete_range  I,  discrete_range|) 

3.6.2 

aggregate  ::= 

(component_association  |,  component_association|) 

component_association 

(choice  f|  choicel  =>  I expression 

choice  simple_expression  | discrete_range  | others 


3.7 

•record_type_defmition  ::= 

record 

componentjist 

end  record 

component_lis!t  ::= 

|object_declaration|  |variant_part|  | null; 

variant_part  ::= 

case  discriminant  of 

Iwhen  choice  ||  choicel  => 
componentjist  | 

end 


discriminant  ::=  constant  component_name 

3.7.3 

discriminant_constraint  ::=  aggregate 
3 8 


access_type_definition 


4.1 


type 


name 

identifier  | inoexed_component 

| selected_component  | predefined  .attribute 


indexed_component 
selected  .component 
predefined_attribute 


4 2 


literal  ::= 

number  | enumerationjiteral  | character_string  | null 


4.3 


variable  name  |(discrete_range)|  | name.all 


4.4 

expression 

relation  (and  relation  | 

I relation  lor  relation  | 

I relation  Ixor  relation) 

relation  ::= 

simple_expression  |relational_operator  simple_expression| 
| simple_expression  Inotl  in  range 
| simple_expression  Inotl  In  type_mark  Iconstraintl 

simple_expression 

|unary_operator|  term  |adding_operator  term  I 
term  factor  |multiplying_operator  factorl 
♦actor  primary  |»*  primaryl 
primary  ::= 

literal  | aggregate  | variable  | allocator 
I subprogram_call  | qualified_expression  | (expression) 


4.5 

logical_operator 

relational_operator  = I /=  I < I <= 

adding_operator 
unary.operator 
multiplying  ..operator 
exponentiating_operator 

4.6 

qualified_expression 

type_mark(expres8ion)  | type.  mark  aggregate 


and  | or  | 

= I /=  I 

+ I - I 

+ I - I 

* I / I 


< I 

& 

not 

mod 


>= 


:=  namelexpression  |,  expression!) 
:=  name  . identifier 
:=  name  ' identifier 


4.7 

allocator  ::= 


qualified  ..expression 


E-2 


1 


5 


5 5 


sequence..of  .statements  ::=  jststementl 
statement 

simple_statement  | compound  , statement 
I <<  identifier  statement 


simple_statement  ::= 

assignment-statement 
I exit-statement 
I goto_statement 
| initiate-statement 
I raise-statement 
I code-statement 


I subprogram-call_statement 
j return-statement 
I assert_statement 
I delay-statement 
I abort-statement 
I null; 


case_statement 

case  expression  of 

I when  choice  ||  choice  I ->  sequence_of-Statemems| 

end  case 

5 6 

loop_statement  |iteration_specification|  basic_loop 

basic.Joop 

loop 

sequence,  of-statements 
end  loop  (identifier!; 


compound-statement 

if_statement  | case-statement 
I loop-statement  j accept-statement 
I select-statement  | block 


iteration,  specification 

for  loop  .parameter  in  ireversel  discrete,  range 
I while  condition 

loop..parameter  identifier 


5.1 


5 7 


assignment-statement  variable  :=  expression  exit-statement  exit  |identifier|  |when  condition!; 


5.2 

subprogram_call_statement  ::=  subprogram-call; 

subprogram. call  ::= 
subprogram- name 

((parameter,  association  (,  parameter_association|)| 

parameter-association  :;= 

|formal_parameter  :=]  actual-parameter 
I |formal_parameter  =:J  actual-parameter 
I |formal_parameter  ;=:|  actual  .parameter 


5.8 

goto-statement  goto  identifier: 

59 

assert.statement  assert  condition; 

6 1 

declarative,  part  : luse.clausei 

Ideclarationl  (representation. specification!  (bodyl 

body  (visibility  restriction!  unit-body  | body.stub 


formal-parameter  ::=  identifier 
actual-parameter  ..  expression 


unit  .body 

subprogram  body  | module,  specification  ( module.bods 
6.2 


5.3 

return-statement  ::  return  (expression!; 


subprogram  declaration 

subprogram-specification : 

| subprogram-nature  designator  is  generic-instantiation. 


5 4 

if_st.rtement  :;= 

if  condition  then 
sequence_of_statements 
I elsif  condition  then 
sequence_of  .statements  I 
I else 

sequence.of  statements! 

end  H; 


subprogram  specification  ::  IgeneriC-Clausel 
subprogram  .nature  designator  |formal_part| 
(return  type  mark  |constraint|( 

subprogram  nature  function  | procedure 

designator  identifier  | character.string 

formal-part  :: 

(parameter-declaration  |;  parameter-declaration  1 1 


condition 

expression  land  then  expression! 
| expression  lor  alee  expression) 


parameter  declaration 

identifier  ..list  mode  type-mark  (constraint!  |:  expression! 
mode  |in|  | out  I in  out 


i 
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subprogram  .body 

subprogram-specification  is 
declarative-part 
begin 

sequence_of_statements 
I •«captKMi 

‘exception-handler  1 1 
and  Idesignator): 


6 7 


use_clause  usa  modi//e_ na me  |,  lodo/e— namel. 


8.5 

renaming_dacl8ration  ::= 

identifier  : type_mark  rename*  name; 

I identifier  ; exception  renamee  name; 

I subprogram_nature  designator  renames  |name.|designator; 
I module_nature  identifier  renames  name; 


block  :;= 

I declare 

declsrative_part| 

begin 

sequence  _of_statements 


9.3 

initiate-statement  ;;= 

initiate  task— designs' or  |,  task-designator  |; 


1 exception 

|exception_handler|| 
end  |identifier|; 


task-designator  :.=  fas*_name  |(discrete_range)| 


7.1 

module-declaration 

I visibility-restriction  | module-specification 
I module-nature  identifier  lidiscrete-rangell 
is  generic-instantiation; 

module-specification 
I generic_clause| 

modu!e_n^ture  identifier  ((discrete-range)  1 (is 
declarative-part 

I private 

declarative_part| 
end  lidentifierfl; 

module,  nature  ::=  package  | task 

module-body  ;:= 

module-nature  body  identifier  is 
declarative_part 

l begin 

sequence-of-Statements| 

I exception 

I exception-handler  1 1 
end  I identifier!: 


7 4 


9.5 

entry-declaration  ;•.= 

entiy  identifier  lidiscrete-rangell  |formal_part|; 
accept-Siatement 

accept  entry-name  Iformal  part!  Ido 
sequence_of-Statements 
end  lidentifierfl; 


9.6 

delay-statement  ::=  delay  simple. expression; 


9.7 

select-statement  ::= 

select 

I when  condition  =>| 
select-alternative 
I or  (when  condition  =>| 
select-Bltemativel 

I else 

sequence-of_statements| 

end  select: 


private-type_declaration  ::= 

I restricted!  type  identifier  Is  private; 

83 

visibility-restriction  ::==  restricted  |visibi*ity_list| 


select-alternative  ::= 

accept-statement  |sequence_of_statements| 
| delay-statement  |sequence_of_statements| 


9.10 


visibility-list  .:=  (un/r_na me  I.  im/f-namell  abort-statement  abort  task-designator  I. task-designate  I; 


I 


ampliation  ::=  Icompitation.unitl 
> ompilation.unit 

I visibility  restriction  lleeparatel  unit_body 


representation  specification  ::= 

packing  .specification  | length. .specification 

I record  .type.representation  | address.specitication 
I enumeration,  type  .representation 


body_stub  ::= 

subprogram  specification  it  separate; 

| module.nature  body  identifier  ia  saparata: 


packing_specification  for  fype_nBme  uaa  packing 


e>ception_declaratinn  ::=  identifier Jist  . exception 


length.specification  ::=  for  name  use  static  expression; 


exception  .handler 

whan  exception_choice  ||  exception_choicel  => 
sequence,  of.  statements 

exception  ..choice  ::=  exception  name  | others 


enumeration_type_representation  ::= 
for  rype.name  use  aggregate: 


raise.statement  ::=  raise  lexeepr/orj.namel; 


record_type  representation 
for  fype.name  use 

record  lalignment_clause;| 
\componentjnama  location:| 

and  record; 


generic_clause  :;= 

generic  |(generic_parameter  |;  generic_parameter|)| 

generic_parameter  ::= 

parameter  .declaration 

| subprogram_specification  Its  Iname  Idesignatorl 

j | restricted  I type  identifier 


location  ::  at  statrc.expression  range  range 
alignment_clause  : at  mod  sfar/'c.expression 


generic. instantiation  ;:= 

now  name  |(peneric_association  |,  generic_association| 

generic.association  :;= 

parameter. association 
| IformaLparameter  1st  Iname. Idesignator 
j IformaLparameter  iai  type_mark 


address  specification 

for  name  use  at  static,  expression; 


code,  statement  qualified. expression; 
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The  Green  language  is  the  result  of  a collective  effort  to  design 
a language  satisfying  the  Steelman  requirements.  The  design 
team  was  led  by  Jean  D.  Ichbiah  and  has  included  Bernd  Krieg- 
Brueckner,  Brian  A.  Wichmann.  Henry  F.  Ledgard.  Jean-Claude 
Heliard,  Jean-Raymond  Abrial,  John  G.P.  Barnes,  and  Olivier 
Roubine.  In  addition,  major  contributions  were  provided  by  G. 
Ferran.  I.C.  Pyle,  SA  Schuman,  and  S.C.  Vestal. 

Two  parallel  efforts  started  in  the  second  phase  of  this  design 
had  a deep  influence  on  the  language.  One  was  the  design  of  a 
test  translator,  with  the  participation  of  K.  Ripken,  P.  Boutlier. 
J.F.  Hueras,  and  R.G.  Lange.  The  other  was  the  development  of 
a forma!  definition  using  denotational  semantics,  with  the  par- 
ticipation of  V.  Donzeau-Gouge.  G.  Kahn,  and  B Lang.  The 
entire  effort  benefitted  from  the  dedicated  support  of  Lyn 
Churchill  and  W.L.  Heimerdinger. 

At  various  stages  of  this  project  several  persons  had  a con- 
structive influence  with  their  comments,  criticisms  and  sugges- 
tions. They  are  P.  Brinch  Hansen,  DA.  Fisher,  G.  Goos.  CA  R. 
Hoare,  M.  Woodger,  and  Mark  Rain. 

Over  the  two  years  spent  on  this  project,  three  intense  one- 
week  design  reviews  were  conducted  with  the  participation  of 
J.B.  Goodenough.  H.  Harte,  M.  Kronental,  K.  Correll,  R.  Firth. 
A.N.  Habermann.  J.  Teller,  P.  Wegner,  and  P.  R.  Wetherall. 

These  reviews,  other  comments  by  E.  Boebert.  P.  Bonnard,  T. 
Frogatt,  H.  Ganzinger,  C.  Hewitt.  J.L.  Mansion.  F.  Mine/.  E. 
Morel,  J.  Roehrich,  A Singer,  D.  S/osberg,  and  I.C.  Wand;  the 
numerous  evaluation  reports  received  on  the  preliminary 
design,  the  on-going  work  of  the  IFIP  Working  Group  2.4  on 
system  implementation  languages,  and  that  of  LTPL-E  of  Pur- 
due Europe,  all  had  a decisive  influence  on  the  final  shape  of 
the  Green  language. 
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1.  Introduction 


This  document,  the  Rationale  for  the  design  of  the  Green  programming  language,  and  the  compa- 
nion Reference  Manual,  are  the  two  defining  documents  for  the  Green  language  They  serve  dif- 
ferent purposes. 

The  Reference  Manual  contains  a complete  and  concise  definition  of  the  language.  Following 
Wirth  we  believe  in  the  virtue  of  having  a rather  short  reference  manual.  This  has  the  advantage  of 
providing  the  information  in  a form  that  can  easily  be  consulted,  read  and  reread  several  times,  as 
the  basis  for  developing  a good  familiarity  with  the  language. 

Having  a short  reference  manual  however  does  not  permit  the  infusion  of  much  motivational  infor- 
mation, and  more  generally,  of  information  describing  the  reasons  behind  the  major  design  deci- 
sions. Neither  does  it  permit  the  insertion  of  the  larger  examples  that  are  yet  essential  to  help  the 
reader  get  a better  feeling  for  the  language,  and  for  the  interaction  among  its  features. 

The  Rationale  is  meant  to  serve  precisely  that  purpose.  It  is  divided  in  chapters  covering  different 
aspects  of  the  language.  Most  chapters  of  the  Rationale  correspond  to  chapters  of  the  Reference 
Manual.  Expressions  and  statements  are  here  regrouped  in  a single  chapter,  since  the  subject  is 
fairly  classical.  Conversely,  in  view  of  the  importance  of  the  subjects,  special  chapters  are  devoted 
to  numeric  types  and  to  access  types,  in  addition  to  the  chapter  on  types.  All  chapters  of  the 
Rationale  are  fairly  independent  (at  the  cost  of  some  repetition)  and  can  be  read  in  any  order  after 
an  initial  pass  over  the  Reference  Manual. 

Most  chapters  of  the  Rationale  have  a common  structure.  They  start  with  an  introduction  to  the 
topic  discussed.  An  informal  introduction  to  the  language  features  follows.  This  informal  introduc- 
tion is  made  in  terms  of  examples  chosen  to  reflect  the  major  classes  of  uses  of  the  features  con- 
sidered. Some  of  these  examples  may  be  viewed  as  skeletons  of  actual  systems. 

We  believe  that  the  reader  will  get  the  spirit  of  the  language  reading  these  examples.  They  should 
help  him  develop  an  intuition  for  programming  style  in  the  Green  language. 

A discussion  of  the  technical  issues  follows  the  informal  introduction.  Such  discussions  cover  the 
major  design  decisions,  their  justification,  and  the  interactions  with  other  aspects  of  the  language. 
In  particular  these  discussions  consider  implementability.  designing  a programming  language 
without  a deep  concern  for  implementability  would  be  little  more  than  an  exercise  in  style.  Accor- 
dingly, implementability  has  been  an  overriding  concern  in  this  design. 

The  main  source  of  inspiration  for  the  Green  language  is  the  programming  language  Pascal  and  its 
later  derivatives.  Pascal  itself  only  meets  a small  part  of  the  Steelman  requirements.  Merely  to 
attempt  to  extend  Pascal  would  have  been  neither  feasible  nor  a desirable  approach.  Neither  the 
simplicity  nor  the  elegance  that  Pascal  derives  from  its  careful  adaptation  to  its  problem  domain 
could  be  retained  in  such  an  approach.  The  extensions  would  inevitably  interact  with  each  other  in 
undesirable  ways.  Hence,  a goal  in  the  design  of  the  Green  language  was  to  retain  the  Pascal 
spirit  of  simplicity  and  elegance  but  not  necessarily  the  form  of  each  Pascal  feature,  since  the 
problem  domain  defined  by  the  Steelman  requirement  is  much  more  ambitious. 

How  should  the  Green  documents  be  read?  Assuming  a basic  knowledge  of  Pascal,  we  recom- 
mend that  the  reader  start  with  a quick  first  pass  of  the  Reference  Manual.  After  this  pass,  the 
various  informal  presentations  included  in  the  Rationale  should  provide  a good  basis  for  a second 
reading  of  the  Reference  Manual.  The  sections  on  technical  issues  should  probably  be  read  last. 
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2.  Lexical  and  Textual  Structure 


A program  is  a text  specifying  actions  to  be  performed  by  a computer.  Programs  are  written  by 
programmers  and  are  processed  by  mechanical  translators.  The  need  to  accommodate  these  two 
forms  of  communication  is  omnipresent  at  every  level  of  consideration  of  a programming 
language,  including  the  lowest  levels  where  we  are  only  concerned  with  the  physical  appearance 
of  a program  text. 

The  lexical  and  textual  structure  of  a programming  language  is  of  course  important  for  ease  of 
program  translation,  and  for  translation  time  error  detection.  Its  importance  is  even  greater  for 
readability  (logical  error  detection)  and  teachability  and  these  have  been  given  major  consideration 
in  the  design  of  the  lexical  and  textual  structure  of  the  Green  language.  We  believe  that  our  under- 
standing of  programs  can  be  greatly  simplified  if  our  intuition  is  able  to  rely  on  textual  forms  that 
convey  the  logical  structure  of  the  program.  This  justifies  the  special  attention  devoted  to  struc- 
tural analogies. 


2.1  Lexical  Structure 


A program  is  written  in  characters  forming  lines  on  the  printed  page.  The  arrangement  on  the  page 
is  primarily  to  assist  the  human  reader,  and  consequently  is  mainly  in  a free  format.  Programs  are 
required  to  have  a representation  in  the  ASCII  character  set,  and  may  contain  both  upper  case  and 
lower  case  letters.  In  addition,  every  source  program  can  be  converted  into  an  equivalent  program 
that  only  uses  a 55  character  subset  of  ASCII. 

On  a higher  level  than  that  of  characters,  a program  is  considered  to  consist  of  lexical  units.  Both 
the  machine  and  the  human  interpreter  of  programs  will  tend  to  work  in  lexical  units,  so  it  is  impor- 
tant that  such  units  should  be  clearly  specified.  Lexical  units  are  clearly  delineated  and  may  not 
straddle  line  boundaries  - a restriction  that  assists  human  reading  and  also  compiler  error  recovery. 
The  lexical  units  are: 

• Identifiers,  including  reserved  words  and  predefined  attributes 

• Single-  and  double-character  delimiters 

• Numbers  (integer  and  real  numbers) 

• Character  strings 

In  addition,  a program  text  can  include  elements  that  have  no  influence  on  the  meaning  of  a 
program  but  are  intended  for  the  human  reader  or  for  the  compiler.  These  are 

• Comments 

• Pragmas 


2-1 


Identifiers  start  with  a letter  which  may  be  followed  by  a sequence  of  letters  and  digits.  In  addition, 
an  underscore  may  appear  within  an  identifier.  This  underscore  is  significant  and  plays  the  role  of 
the  space  in  ordinary  prose  (but  without  breaking  the  integrity  of  the  identifier).  The  need  for  such 
an  underscore  is  seen  from  good  choices  of  names  such  as  BYTES_PER_WORD  rather  than 
BYTESPERWOHD. 

Reserved  words  are  distinguished  from  program  identifiers;  there  are  62  such  words.  Reserved 
words  cannot  be  redeclared.  Hence  programmers  cannot  write  obscure  programs  by  redefining  the 
meaning  of  such  words.  Similarly  programs  can  be  highlighted  by  special  printing  of  reserved 
words  on  an  appropriate  output  device.  The  method  chosen  in  this  manual  is  boldface  (and  lower 
case).  Since  the  language  uses  only  one  alphabetic  font,  one  could  envisage  methods  of 
highlighting  the  reserved  words  by  the  use  of  a different  font,  such  as  lower  case,  italics,  underlin- 
ing, etc.  All  these  methods  have  the  important  property  that  the  method  of  typing  programs  with 
the  ASCII  character  set  is  not  prejudiced.  This  is  important,  since  it  is  currently  possible  to  get 
excellent  representations  of  programs  via  graphical  printers  of  photocomposition  machines. 

Names  for  predefined  attributes  are  from  a distinct  list,  but  are  not  reserved  words  since  they  are 
always  preceded  by  a prime  character  and  can  thus  be  distinguished  at  the  lexical  level.  The  Green 
language  uses  predefined  attributes  to  express  predefined  properties  and  environment  enquiries. 
Other  languages  have  used  dot  notation  or  functional  notation  for  this  purpose.  Both  of  these 
forms  have  the  disadvantage  of  restricting  the  user's  choice  of  names. 

For  example  if  the  address  of  an  object  were  denoted  by  a function,  this  function  would  have  to  be 
overloaded  on  all  data  types;  any  user  definition  of  ADDRESS  would  hide  the  predefined  one  and 
thus  make  it  unavailable.  Similarly,  dot  notation  would  prevent  declaration  of  record  components 
with  the  same  identifier.  Neither  of  these  situations  is  acceptable  in  light  of  the  fact  that  the 
number  of  predefined  attributes  can  be  large  and  that  some  of  them  may  be  particular  to  an 
implementation.  All  these  problems  are  avoided  with  the  Green  notation. 

The  choice  of  identifiers  for  reserved  words  and  predefined  attributes  depends  primarily  on  con- 
vention. Preference  is  given  to  full  English  words  rather  than  abbreviations.  For  instance, 
procedure  is  used  rather  than  proc  (in  Algol  68)  and  conatent  rather  than  const  (in  Pascal).  Shorter 
words  were  also  given  preference,  for  example  access  is  used  in  preference  to  reference,  and  task 
is  used  in  preference  to  process. 

The  following  special  characters  can  be  used  as  delimiters  between  lexical  units: 

&■()*  + , -./:;<  = > | 

Further  delimiters  are  constructed  by  juxtaposition  of  two  (or  three)  such  characters  as  follows: 

=>  ..  **  ■=  =-.  :=;  /=  >=  <=  <<  >> 

Naturally,  where  possible,  printers  may  choose  to  print  /=  as  * and  similarly  >=  as  > and  <=  as  <. 

Numeric  literals  are  all  introduced  by  an  initial  digit.  A simple  digit  sequence  is  a decimal  integer. 
For  other  bases  from  2 up  to  1 6 the  base  is  given  first  in  decimal  form  and  is  followed  by  a # sign 
(or  the  replacement  character  :)  and  by  the  sequence  of  digits.  These  may  include  the  letters  A to  F 
for  bases  greater  than  ten.  Thus,  the  conventional  methods  of  setting  bit  patterns  in  binary,  octal  or 
hexadecimal  are  provided. 
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Real  numbers  must  contain  a decimal  point  or  an  exponent  or  both.  The  reasons  for  this  are 
covered  in  the  chapter  on  numerics  (see  5).  The  underscore  is  permitted  within  a number  to  break 
up  long  sequences  of  digits,  a requirement  that  has  long  been  recognized  by  printers. 


Another  form  of  lexical  unit  is  the  string  (and  character  literal).  The  characters  are  enclosed  in 
quotes  ",  where  two  successive  quotes  represent  the  quote  itself.  Strings  in  the  program  are 
limited  to  a single  line,  to  reduce  the  consequences  of  program  errors  due  to  omission  of  a quote 
character  or  ambiguity  with  respect  to  space  characters.  To  specify  a long  string,  the  string  is  split 
across  multiple  lines  and  connecteo  by  the  catenation  operator.  This  is  possible  because  catena- 
tion will  be  performed  by  the  compiler.  Automatic  paragraphing  processors  may  have  to  split  a str- 
ing in  order  to  give  a satisfactory  layout.  Apart  from  long  strings,  there  may  be  a need  to  split  str- 
ings that  contain  control  characters  or  characters  that  are  not  in  the  55  character  subset  of  ASCII, 
to  permit  these  to  be  represented.  Examples  of  strings  are  as  follows: 

"A  LONG  LINE  OF  PRINTED  OUTPUT  WHICH"  & 

" IS  CONTINUED  ON  THE  NEXT  LINE  OF  THE  PROGRAM  " 

"Strings  start  with  the  ""  character." 

"END  OF  LINE"  & CR  & LF  & "START  OF  NEXT  LINE" 

Comments  may  appear  alone  on  a line  or  at  the  end  of  a line.  As  an  end  of  line  remark,  the  com- 
ment should  appear  as  an  explanation  of  the  preceding  text  — hence  the  use  of  the  double  hyphen 
is  appropriate,  as  illustrated  by  this  sentence.  For  simplicity,  no  space  is  permitted  between  the 
two  hyphens.  No  form  of  embedded  comments  (within  a line  of  text)  is  provided  as  their  use  is  too 
slight  . od  not  worth  the  extra  complexity.  For  a further  discussion  of  comments  see  |SW  74|. 

A pragma  (from  the  Greek  word  meaning  action)  is  used  to  direct  the  translation  system  in  par- 
ticular ways,  but  has  no  effect  on  the  semantics  of  a program  Pragmas  are  used  to  control  source 
text  and  listing,  to  define  an  object  configuration  (for  example  the  size  of  memory),  to  control 
features  of  the  code  generated  (particularly  the  level  of  diagnostics),  etc.  Such  directives  are  not 
likely  to  be  related  to  the  rest  of  the  language  in  an  obvious  way.  Hence  the  form  taken  should  not 
intrude  upon  the  language,  but  it  should  be  uniform. 

The  general  form  of  pragmas  is  defined  by  the  language.  They  start  with  the  reserved  word  pragma 
and  a pragma  identifier  optionally  followed  by  a list  of  identifiers,  strings,  and  numbers  enclosed 
within  parentheses.  The  pragma  ends  with  a semicolon  and  may  appear  at  any  place  where  a 
declaration  or  statement  may  appear.  Examples  of  pragmas  are  as  follows: 

pragma  LIST(ON); 
pragma  OPTIMIZE  (SPACE); 
pragma  INCLUDE  ("common_options"); 
pragma  SUPPRESS(OVERFLOW); 

Some  pragmas  are  defined  by  the  language  (see  appendix  B of  the  Reference  Manual).  It  is 
expected  that  other  pragmas  will  be  defined  as  part  of  the  support  environment  developed  around 
the  language. 


2 3 


1 


2.2  Textual  Structure 


Above  the  lexical  level,  the  text  of  a program  has  structure  as  an  arrangement  of  lexical  umts.  This 
structure  is  described  by  syntax  in  the  conventional  manner.  However,  a number  of  issues  require 
separate  exposition  to  clarify  the  decirms  taken. 

Declarations  and  statements  are  always  terminated  by  semicolons.  This  departure  from  the  Pascal 
practice,  in  which  a semicolon  is  used  as  a separator,  requires  justification.  Analyses  of  program- 
mer errors  support  the  use  of  the  semicolon  as  a terminator  |GH  ‘’5).  Also,  inserting  another 
declaration  or  statement  is  eased  by  this  convention,  since  normal  layout  places  the  semicolon  at 
the  end  of  the  line  (requiring  a change  to  two  lines  in  the  case  of  a separator). 

The  additional  required  semicolon  also  aids  recovery  by  the  compiler  after  a syntax  error.  On  the 
other  hand  if  semicolon  is  a terminator,  recovery  from  a missing  semicoion  may  be  trivial  for  the 
parser 

Many  program  structures  have  simple  brackets,  for  example  the  loop  and  end  loop  of  the  iterative 
statement,  or  begin  and  end  of  the  subprogram  body.  Such  structures  can  be  indicated  clearly  by 
good  program  layout,  which  can  be  done  automatically.  Structures  have  been  chosen  to  aid 
automatic  program  layout  because  the  consistency  of  presentation  is  a significant  advantage  to 
the  reader  It  should  be  noted  that  conditional  expressions  (not  present  in  Pascal  or  this  language) 
pose  severe  problems  for  automatic  layout. 

Several  textual  program  constructs  exhibit  a comb-like  structure.  This  structure  has  simple 
bracketing  and  is  best  illustrated  with  the  conditional  statement  as  in  the  following  example. 


H A = 1 then 

SI: 

A = 2 then 

S2; 

eleif  A = 3 then 

S3. 

end  if: 

t 

The  structure  has  three  parts:  an  initial  strong  opening  bracket  (if) . a set  of  weaker  delimiters  (etsif) 
and  a strong  closing  bracket(end  If). 

The  equivalent  code  can  be  written  with  the  case  comb  structure: 


case  A of 

when  ! 

St: 

when  2 

S2; 

= > 

when  3 

S3: 

1 end  case: 

Note  that  an  else  S4  added  to  the  conditional  statement  would  correspond  to  the  other*  construct 
in  the  case  statement 


Further  examples  of  the  comb-structure  are 


procedure  P is 

begin 

exception 

end  P; 

select 

or  when  A => 

or  when  B > 


I end  select: 

It  will  be  noted  that  each  large-scale  comb  structure  has  the  terminating  reserved  word  end  For' 
statements  and  declarations  this  is  followed  by  an  initial  reserved  word  as  well: 


if 

end 

if 

loop 

end 

loop 

CBM 

end 

case 

•oloci 

end 

select 

record 

end 

record 

For  named  program  units  such  as  subprograms  and  modules  (and  also  accept  statements  since 
they  act  as  bodies  for  the  corresponding  entries)  the  name  of  the  unit  may  follow  the  final  end  to 
assist  recognition  of  the  structure. 

In  general,  language  constructs  which  do  not  express  similar  ideas  should  not  look  similar  Thus, 
unlike  Pascal,  which  uses  a colon  in  both  cases,  the  Green  language  uses  different  notations  tor 
statement  labels  (for  goto  s atements)  and  for  choices  (in  case  statements)  Statement  labels  have 
angle  brackets  <<  placed  around  the  identifier  of  the  label.  They  emphasize  that  mis  is  a 
special  point  in  the  program.  Conversely,  choices  exprer ; preconditions  for  executing  the  state 
ments  which  follow.  Choices  thus  are  indicated  in  clauses  of  the  form 

when  ...  => 

The  same  structure  has  also  been  used  in  select  statements  since  it  corresponds  to  the  same  idea 
of  a precondition. 

Whenever  possible  a uniform  notation  is  used  for  similar  constructs.  The  clearest  example  of  this  is 
the  case  structure  which  is  used  for  variant  records  as  well  as  statement  selections.  Although  in 
Pascal  variant  records  and  case  statements  are  similar  constructs  their  notation  is  not  uniform. 
This  causes  difficulty  in  teaching  the  language  and  is  a source  of  errors  The  contrast  is  best 
illustrated  by  an  example 


1 
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A graphics  data  structure  in  Pascal 


type  FIGTYPE  (POINT,  CIRCLE.  TRIANGLE); 
type  FIGURE  = 

record 

X.  Y:  REAL; 
case  F:  FIGTYPE  of 
POINT- 

CIRCLE:  (RADIUS:  REAL): 

TRIANGLE: 

(SIDE:  array  11  ..  2|  of 

record 

ANGLE.  LENGTH:  REAL; 

end 

) 

end 

The  equivalent  structure  in  the  Green  language. 

type  FIGURE  is 
record 

X.Y  : REAL; 

F : constant  (hOINT.  CIRCLE,  TRIANGLE); 

case  F of 

when  POINT  =>  null; 

when  CIRCLE  =>  RADIUS  : REAL; 

when  TRIANGLE  => 

SIDE:  array  (1  .2)  of 

record 

ANGLE.  LENGTH:  REAL; 

end  record: 

end  case; 

end  record: 

A case  statement  in  Pascal 

case  DAY  of 

MON  : STARTWORK; 

FRI  : TIDYUP; 

TUE.WED.THU  : WORK; 

SAT.  SUN: 


The  equivalent  case  statement  in  the  Green  language 
case  DAY  of 

when  MON  =>  START_WORK; 
when  FRI  =>  TIDY.UP; 
when  TUE  . THU  =>  WORK; 
when  SAT  | SUN  =>  null: 

end  case; 


The  structural  analogy  in  the  Green  language  between  the  declarotive  case  (variant  part)  and  the 
case  statement  should  assist  the  human  readei  and  help  in  learning  the  language  The  approach 
will  also  simplify  pretty  printing  of  programs  by  mechanical  tools  which  do  not  necessadly  have 
access  to  declarative  information. 

A similar  analogy  exists  between  the  case  and  the  select  statement  Other  structural  analogies, 
which  are  adequately  reflected  by  the  syntax,  correspond  to  the  textual  structure  of  functions, 
procedures,  tasks,  packages  and  blocks. 


function  F Is 

task  body  T Is 

begin 

begin 

»1 

and  F; 

end  T. 

i 

procedure  P Is 

declare 

begin 

begin 

end  P. 

end: 

□ 


task  T Is 
end  T; 


package  S Is 

and  S; 


These  structural  analogies  have  been  used  quite  systematically.  They  should  develop  a feeling  of 
familiarity  for  the  render  and  simplify  the  teaching  of  the  language 
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3.  Expressions  and  Statements 


n 


Programs  achieve  actions  by  executing  statements.  These  may  contain  expressions  that  are  for- 
mulas defining  the  computation  of  values.  Expressions  (including  their  constituent  constants, 
aggregates,  and  variables)  and  statements  are  fairly  classical  aspects  of  most  programming 
languages.  Hence  we  limit  the  discussion  to  the  most  prominent  points. 


3.1  Variables  and  Constants 


Although  the  approach  to  variables  follows  Pascal,  there  are  some  differences.  First,  initialization 
expressions  can  be  inserted  at  the  point  of  declaration.  This  avoids  long  initialization  sequences 
that  are  divorced  from  the  declarative  code  and  hence  hard  to  locate.  Second,  references  to  array 
components  use  round  rather  than  square  brackets.  The  advantage  of  this  is  a uniform  notation 
within  an  expression  for  reference  to  array  components  and  for  function  calls.  The  same  argument 
of  uniform  referents  [Ro  70J  justifies  using  the  same  syntax  for  component  selection  of  records 
whether  they  are  statically  or  dynamically  allocated  (see  Chapter  6). 

A delicate  balance  is  necessary  in  the  handling  of  constants  and  variables.  Reliability  and  security 
demand  that  the  two  concepts  be  clearly  separated.  On  the  other  hand  it  is  convenient  if  a 
program  can  be  changed  by  simply  altering  the  declaration  of  an  identifier  from  a variable  to  a con- 
stant. 

The  Green  language  meets  these  goals  by  having  two  distinct  but  related  forms  of  declarations  for 
the  two  concepts.  Thus 

C : constant  INTEGER  :=  30CL000; 

is  a constant  declaration,  whereas  the  following  declaration  defines  a variable  with  an  initial  value. 
SPEED  : INTEGER  :=  C/1 500; 

The  handling  of  constants  in  Pascal  is  rather  inflexible.  All  constants  must  appear  before  the  other 
declarations  |WSH  77J  and  no  translation  time  evaluation  is  allowed. 

The  Green  language  allows  constant  valued  expressions  wherever  a constant  is  permitted. 
Furthermore,  it  follows  Algol  68  in  permitting  constants  whose  values  are  determinable  at  scope 
entry  time.  The  constant  qualifier  which  appears  in  the  declaration  of  an  identifier  means  that  the 
value  of  the  corresponding  object  cannot  be  altered  after  the  initialization.  Hence  the  translator 
shall  forbid  any  attempt  to  alter  its  value.  However  it  does  not  mean  that  this  value  must  neces- 
sarily be  known  at  translation  time.  Constant  declarations  are  like  other  declarations;  they  may  be 
mixed  in  groupings  that  reflect  the  logical  needs  of  a program. 
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3.2  Aggregates 


Aggregates  denote  values  of  array  and  record  types.  In  both  cases  the  Green  language  admits  a 
positional  notation  in  which  the  aggregate  is  given  by  a sequence  of  values,  implicitly  associated 
with  the  corresponding  components.  Another  notation  that  is  often  preferable  is  also  provided,  in 
which  the  association  of  given  values  to  the  components  is  defined  by  explicit  selectors  called 
choices.  This  discussion  concentrates  on  array  aggregates. 

An  array  aggregate  defines  an  array  value.  As  for  literals  of  other  types,  the  question  of  the  type  of 
an  array  aggregate  has  to  be  solved.  By  analogy  consider  the  assignment 

I :=  8 + 5; 

Assuming  that  the  variable  I is  of  type  MY_INT£GER,  we  are  able  to  identify  a operation  that 
takes  two  arguments  of  type  MYJNTEGER  and  delivers  a result  of  type  MYJNTEGER.  Hence  we 
may  interpret  the  literals  8 and  5 as  being  of  type  MYJNTEGER  and  perform  the  corresponding 
operation,  provided  that  these  literals  satisfy  the  range  constraint  of  the  type  MYJNTEGER. 

The  same  logic  applies  to  an  assignment  involving  an  array  aggregate.  An  array  aggregate  is  an 
array  value  of  a certain  array  type  which  must  be  identified  from  the  context.  This  means  that  we 
need  to  identify  the  type  and  constraint  of  the  array  value: 

• the  component  type 

• the  number  of  dimensions 

• the  index  type  for  each  dimension 

• the  bounds  of  each  dimension 

As  in  the  case  of  integer  literals,  we  must  be  able  to  deduce  all  these  elements  from  the  context, 
otherwise  the  aggregate  is  ambiguous.  Consider  for  example  an  array  A defined  by 

type  VECTOR  m array  (NATURAL)  of  INTEGER; 

A : VECTOR!  1 ..  10); 

We  first  examine* non-positional  aggregates  and  then  positional  aggregates. 

Non-Positional  Aggregates 
Suppose  that  we  have 

A ;=  (1  ..  6 =>  0,  7 ..  10  =>  100); 

The  aggregate  must  describe  a value  of  type  VECTOR,  that  is.  a one  dimensional  array  of  integers. 
In  addition,  its  indices  must  be  natural  numbers  in  the  range  1 ..  10. 

Having  derived  this  information  from  the  analysis  of 

A := 

we  can  now  interpret  all  choices  in  the  above  aggregate  as  legitimate  index  values,  since  1,6,  7, 
and  10  are  indices  in  the  range  1.10.  Conversely,  we  would  be  able  to  detect  that  the  following 
aggregate  is  illegal: 


--  illegal! 


A :=  (11  ..  16  =>  0.  17  ..  20  =>  100); 

since  the  index  values  11,  16,  17,  and  20  are  not  in  the  range  1 ..  10. 

Another  possible  viewpoint  for  non-positional  array  aggregates  would  be  to  consider  them  as 
values  independently  of  the  context  and  then  to  invoke  some  sliding  semantics  for  assignments 
and  comparisons.  Such  a semantics  would  permit 

A :=  (101  ..  110  =>  0);  — illegal  in  Green  since  A FIRST  = 1,  A' LAST  = 10 

Such  an  aggregate  would  be  interpreted  as  a value  of  an  array  AGGREGATE  declared  as 
AGGREGATE  : array  (101  ..  110)  of  INTEGER  :=  (101  ..  110  =>  0); 

Then  the  assignment  could  be  interpreted  as  a slice  assignment 
A(1  ..  10)  :=  AGGREGATE  (101  ..  110); 

There  are  several  difficulties  with  this  alternative  semantics  of  named  aggregates.  First,  it  would 

make  the  determination  of  the  bounds  of  an  aggregate  quite  difficult  in  general,  if  not  impossible 
as  in  r 

( 1 5|  1 6 =>  0,  6 ..  8 =>  1,  others  =>  5) 

Second,  this  interpretation  would  not  be  possible  for  index  types  defined  by  enumeration.  Con- 
sider for  example 

type  SCHEDULE  is  array  (DAY  FIRST  . DAY' LAST)  of  BOOLEAN; 
and  an  array  aggregate  such  as 

(WED  ..  SUN  =>  TRUE,  others  =>  FALSE) 

This  aggregate  can  only  mean  that  we  have  TRUE  for  the  days  WED  to  SUN  and  false  for  MON 
and  TUE.  No  sliding  semantics  could  give  this  interpretation. 

For  these  reasons  the  semantics  retained  in  the  Green  language  is  that  the  index  values  given  in 
each  component  association  must  be  index  values  for  an  array  identified  from  the  context. 

Positional  aggregates 

For  positional  aggregates  we  must  take  a different  viewpoint  since  there  are  no  explicit  selectors 
indicating  the  destination  of  each  value.  Conceptually  a positional  aggregate  must  thus  be  viewed 
as  a sequence  of  values  of  the  component  type.  Note  that  this  same  viewpoint  is  taken  when  we 
deal  with  slice  assignments.  Hence 

A :=  (9,  8.  7,  6,  5,  4,  3.  2,  1,  0); 

can  be  interpreted  as  the  sequence  of  assignments 

A(1|  :=  9; 

AI10)  :=  0; 


L 
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This  is  to  be  compared  with 
A Bill  20); 

which  is  interpreted  as  the  sequence  of  assignments 
A(1|  ;=  B(  11); 

A<  10!  ;=  BI20); 


3.3  Expressions 


The  purpose  of  an  expression  is  the  computation  of  a value.  The  evaluation  of  an  expression  is 
conceptually  an  indivisible  operation.  Hence  it  must  be  assumed  that  all  of  the  constituent  expres- 
sions will  be  evaluated  and  that  any  exception  condition  that  can  arise  in  any  part  of  the  expression 
cannot  be  avoided.  In  this  sense 


A = 0 or  K/A  > 10 

is  not  a valid  expression,  since  the  validity  of  the  second  member  depends  on  the  value  of  the  first 
member.  Whenever  there  is  such  a condi  innality  it  must  be  made  explicit  in  a control  structure 
evaSion'  C°nditi°nS  (see  3 7)  in  order  to  emphasue  the  possibility  cf  incomplete 


The  language  provides  six  operator  precede  ■> 
strength. 


listed  below  in  increasing  order  of  binding 


( lowest ) 


( highest ) 


logical 

relational 

adding 

unary 

multiplying 

exponentiating 


and  or  xu< 

/=  < 

+ - & 

+ not 

* / mod 


< = 


>= 


We  found  this  number  of  levels  to  be  the  minimum  number  compatible  with  accepted  practice 
Clearly  different  levels  are  required  for  relational,  adding,  multiplying  and  exponentiation  operators 
unary  does  not  really  constitute  a level).  In  addition,  logical  operators  must  be  on  another  lower 
level  if  expressions  such  as 


A = B or  C = D 


are  to  be  written  without  parentheses.  In  the  case  of  a succession  of  operators  with  the  same 
precedence  the  Green  language  adopts  the  traditional  rule  of  left  to  right  evaluation.  In  addition 

e syntax  requires  explicit  parentheses  in  the  case  of  a succession  of  different  logical  operators 
For  example 


A or  (B  xor  C) 
(A  or  B)  xor  C 
A or  IB  and  C) 
A or  B or  C 
A and  B and  C 


--  parentheses  required 

parentheses  required  (not  always  equal  to  previous  expression) 

— parentheses  required 

— no  need  for  parentheses 

— no  need  for  parentheses 
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In  practice  most  expressions  are  simple;  the  inconvenience  of  parentheses  should  not  be  exag- 
gerated as  programmers  tend  to  introduce  additional  parentheses  for  readability  purposes  (to  reas- 
sure themselves  when  in  doubt)  whether  they  are  required  or  not. 


3.4  Statements 


The  classical  forms  for  sequential  processing  are  included  in  the  Green  language:  assignment 
statements,  subprogram  calls,  conditional,  iterative  and  transfer  statements.  Less  classical  control 
structures  such  as  the  raise  statement  and  the  statements  used  for  parallel  processing  are  discus- 
sed in  later  chapters. 

It  is  convenient  to  distinguish  normal  statements  and  transfer  statements.  For  a normal  statement, 
execution  continues  with  the  following  statement.  For  transfer  statements  [exit,  return,  goto ) con- 
trol will  transfer  to  another  place  in  the  program.  Another  useful  distinction  is  between  simple  and 
compound  statements.  A simple  statement  contains  no  other  statement.  Compound  statements 
may  include  other  sequences  of  statements. 

The  language  follows  the  rule  that  wherever  a statement  may  appear,  a sequence  of  statements 
may  appear.  Tf  s rule  simplifies  program  modification  since  insertion  of  a statement  can  be  done 
without  the  r.ss'!  insert  extra  begin  and  end  delimiters  as  is  the  case  in  Algol  and  Pascal.  State- 
ments of  a seq  jnce  of  statements  are  executed  in  sequence  unless  a transfer  statement  is 
encountered. 

Although  it  is  redundant,  an  explicit  null  statement  has  been  included  in  the  language  for 
readability.  For  instance  if  nothing  is  required  for  a given  alternative  of  a case  statement,  it  is 
preferable  to  state  this  explicitly  with  the  statement 

null. 

rather  than  convey  the  same  impression  by  an  empty  statement  that  could  be  taken  as  an  uninten- 
tional omission. 


3.5  Assignment  Statements 


The  assignment  statement  is  generally  regarded  as  the  simplest  of  all  statements.  In  fact,  this  is 
the  case  only  if  precautions  are  taken  in  its  definition.  Since  calls  to  value-returning  procedures  can 
only  appear  in  an  expression  on  the  right  hand  side  of  an  assignment  (and  since  no  other  side 
effects  are  possible  within  expressions),  the  meaning  of  an  assignment  statement  does  not  depend 
on  whether  its  left  or  right  side  is  evaluated  first.  Flence  an  assignment  may  be  viewed  by  a 
program  reader  as  an  indivisible  action.  The  same  argument  of  simplicity  justifies  Pascal  in  not 
providing  either  multiple  assignment  or  parallel  assignments.  In  any  case,  the  multiple  assignment 
of  Algol  60  is  rarely  used  except  for  initialization  and  also  causes  parsing  problems  for  the  human 
reader. 

Some  additional  precautions  are  required  for  slice  (i.e.  subariay)  assignments.  If  assignment  is  to 
be  permitted  between  slices  it  should  follow  the  same  axiomatic  rules  as  for  ordinary  variable 
assignments.  If  this  were  not  the  case  it  would  be  questionable  to  use  the  same  syntax  tor  two 
operations  which  have  different  logic.  For  example,  after  the  assignments 
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C :=  B: 

A :«  B; 

we  can  deduce  from  the  axiomatics  of  assignment  that  A = C.  This  same  consequence  will  apply 
to  slices  only  if  overlap  is  forbidden.  Consider  for  instance  the  (incorrect)  assignments 

C (1  ..  5)  :=  B(2  . 6); 

B |1  5)  :=  B(2  . 6);  --  illegal  assignment 

Because  of  the  overlap,  we  do  not  have  C(1  ..  5)  = B(1  ..  5)  but  rather  C(1)  = B(2),  C(2)  = B(3), 
C(3)  = B(4),  C(4)  = BI5).  Similarly  the  incorrect  assignments 

C (2  ..  6)  :=  B(1  ..  5); 

B (2  6)  :=  BO  ..  5);  --  illegal  assignment 

would  fail  to  produce  C(2  ..  6)  = B(2  ..  6)  and  the  actual  results  would  even  depend  on  whether  the 
second  assignment  is  considered  to  be  performed  on  an  element-by-element  basis  or  whether  an 
intermediate  copy  is  used. 

In  conclusion,  overlap  in  slice  assignment  is  a form  of  aliasing  that  is  hence  forbidden,  and  causes 
the  exception  OVERLAP_ERROR.  Note  that  overlapping  slice  assignments  have  sometimes  been 
used  in  low-level  programming  to  achieve  an  effect  similar  to  what  can  be  (legally)  performed  with 
an  aggregate  assignment  such  as 

All  . 80)  :=  II  ..  80  " "); 


3.6  If  Statements 


If  statements  are  used  to  select  statement  lists  for  execution  on  the  basis  of  a condition.  The  syn- 
tax 

if  condition  then 

sequence_of_statements 

end  if: 

is  fairly  classical  The  if  and  end  if  bracket  structure  avoids  the  dangling  else  ambiguity.  If  state- 
ments containing  elsif  clauses  can  be  used  to  select  alternative  statement  lists  depending  on  dif- 
ferent conditions: 

if  RAIN  then 

— sequence  of  statements  describing 

— what  to  do  when  it  rains 

elsif  SUN.SHINE  then 

— sequence  of  statements  describing 
--  what  to  do  when  the  sun  shines 

else 

— sequence  of  statements  describing 

— what  to  do  for  othe  weather  conditions 

end  if: 

Strictly  speaking,  elsif  clauses  are  redundant:  the  corresponding  statements  can  always  he  rewrit- 
ten in  the  form  of  nested  if  statements.  However  this  nesting  is  generally  awkward  and  does  not 
convey  the  correct  impression,  namely  that  the  alternatives  are  on  the  same  level,  apart  from  the 
fact  that  the  conditions  should  be  evaluated  in  the  order  in  which  they  appear. 
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3.7  Short  Circuit  Conditions 


Boolean  expressions,  like  other  expressions,  may  be  rearranged  by  the  translator  as  permitted  by 
the  properties  of  their  operators.  Thus  commutativity  can  be  used  in  expressions  such  as  A and  B 
Depending  on  the  complexity  of  the  term  B,  it  may  be  more  efficient  (on  some  but  not  all 
machines)  to  evaluate  B only  when  the  term  A is  true.  This  however  is  an  optimization  decision 
taken  by  the  compiler.  In  any  case  the  expression  A and  B should  always  deliver  the  same  result 
as  B and  A,  and  should  have  no  other  effect. 

In  some  situations,  however,  we  may  want  to  express  a conjunction  of  conditions  where  each  con- 
dition should  be  evaluated  (has  meaning)  only  if  the  previous  condition  is  satisfied.  This  may  be 
done  with  short  circuit  conditions  such  as 

if  I /=  0 and  than  A/I  > B than 

and  if; 

Clearly  it  would  not  be  legal  to  express  this  condition  as  a boolean  expression,  since  an  exception 
would  result  if  I were  zero  and  the  second  term  were  evaluated  first.  Similarly,  short  circuit  dis- 
junctions can  be  expressed  with  or  also  clauses  as  in  the  following  example: 

exit  whan  X = null  or  alaa  X.AGE  = 0. 

In  this  case  the  condition  following  or  alaa  will  only  be  evaluated  if  the  previous  condition  is  not 
satisfied.  Since  the  rules  of  evaluation  of  and  than  clauses  and  or  alaa  clauses  are  thus  contradic- 
tory, the  two  forms  of  clauses  cannot  be  mixed  in  the  same  condition. 

In  Algol  60  one  can  achieve  the  effect  of  short  circuit  evaluation  only  by  use  of  conditional  expres- 
sions, since  complete  evaluation  is  performed  otherwise.  This  leads  to  cumbersome  constructs 
which  are  awkward  to  follow: 

H(U  I /=  0 than  true  alaa  A div  I ■>  B)  than... 

Several  languages  including  Pascal,  do  not  define  how  boolean  conditions  are  to  be  evaluated.  In 
fact  the  Pascal  CDC  6000  series  compiler  uses  complete  evaluation,  whereas  the  ICL  1900  com- 
piler uses  short  circuit,  i.e.,  treats  and  as  and  than,  and  similarly  or  as  or  alaa.  As  a consequence 
programs  based  on  short  circuit  evaluation  will  not  be  transferable.  This  clearly  illustrates  the  need 
for  separating  boolean  operators  from  short  circuit  conditions. 


3.8  Caaa  Statements 


A case  statement  serves  to  execute  one  element  of  a list  of  alternatives  selected  on  the  basis  of 
the  value  of  an  expression.  Each  possible  alternative  is  preceded  by  the  list  of  values  for  which  the 
corresponding  alternative  should  be  selected.  The  main  criteria  in  the  design  of  the  C3se  state- 
ment have  been  reliability  and  generality. 

For  reliability,  the  translator  must  be  given  the  possibility  to  check  for  accidental  omission  of  some 
alternatives.  For  that  reason  it  is  required  that  all  possible  values  of  the  type  of  the  d:scriminating 
expression  be  provided  for  in  the  selections.  Naturally,  a qualified  expression  can  be  used  to 
restrict  this  choice  and  the  selection  others  may  be  used  to  represent  all  values  not  specified.  As 
an  example  consider  the  declarations 
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tyi'#  DAY  is  (MON  TUE.  WED  THU.  FRI.  SAT.  SUN): 
subtyp#  WORK  DAY  is  DAY  rings  MON  FRI. 

subtyps  REST_DAY  is  DAY  rsngs  SAT  SUN: 

D : DAY, 

With  the  above  declarations  all  values  of  the  type  DAY  (the  type  of  D)  must  appear  in  one  selec 
tion.  as  in 

csss  D of 

when  MON  | TUE  | WED  | THU  | FRI  =>  WORK, 
whsn  SAT  j SUN  =>  REST: 

•nd  ciss: 

This  could  have  been  written  in  the  equivalent  form 
ciss  D of 

whsn  MON  | TUE  | WED  | THU  | FRI  =:>  WORK; 

whsn  others  > REST; 
end  case: 

If  it  is  known  in  a given  context  that  the  case  discriminant  belongs  to  a given  subtype,  a case  with 
a qualified  expression  may  be  used.  Only  the  values  of  the  corresponding  subtype  can  appear  in 
the  selections.  Should  the  constraint  not  be  satisfied  (for  example  if  D = SAT),  an  exception 
RANGE_ERROR  would  result. 

ciss  WORK_DAY(D)  of 

whsn  MON  | WED  | FRI  =>  LATE: 
whsn  TUE  | THU  =>  EARLY: 

snd  ciss: 

The  second  concern  in  the  design  of  case  statements  is  generality:  the  syntax  of  selections  should 
accommodate  all  situations  which  are  likely  to  arise,  given  that  the  case  discriminant  has  a dis- 
crete type.  Hence  it  should  permit  lists  of  values  as  well  as  ranges.  Thus  the  first  example  above  is 
more  likely  to  be  written  using  subtype  names: 

can  D of 

when  WORK_DAY' FIRST  . WORK_DAY  LAST  =>  WORK; 
when  REST_DAY‘FIRST  . REST_DAY  LAST  «>  REST; 

end  cm#. 

or  using  the  ranges  directly: 

cii#  D of 

when  MON  ..  FRI  > WORK; 

wh#n  SAT  ..  SUN  REST;  - ^ 

end  cat#: 

Such  ranges  are  very  useful  in  case  selections.  They  avoid  long  lists  that  can  be  tedious  to  read 
and  error  prone 

A very  important  diagnostic  facility  that  the  translator  should  provide  is  the  listing  of  all  values  of 
the  discriminant  type  that  do  not  appear  in  any  listed  choice.  For  an  erroneously  incomplete  case 
statement  the  translator  has  the  information  and  should  provide  it  for  the  programmer.  For 
enumeration  types  with  a large  number  of  values,  should  this  kind  of  diagnostic  not  be  provided  it 
might  be  quite  difficult  for  the  programmer  to  discover  any  missing  values. 
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Case  statements  are  conventionally  implemented  with  an  implicit  transfer  table.  This  table  will 
generally  contain  one  entry  for  each  possible  value  of  the  discriminant  type.  Quite  often  however 
if  some  of  the  alternatives  perform  no  actions,  the  translator  may  optimize  the  code  generated  by 
using  a shorter  table  and  an  explicit  range  check.  As  an  example 

case  0 of 

when  SAT  =>  SHOP; 
when  SUN  =>  SLEEP; 

when  others  =>  null; 

end  case; 

may  be  compiled  to  produce  a code  equivalent  to 

if  D in  REST_DAY  then 
case  REST_DAY(D)  of 
when  SAT  =>  SHOP; 
when  SUN  =>  SLEEP; 

end  case; 

end  if; 

thus  leading  to  a two  entry  transfer  table.  Finally,  case  statements  with  very  sparse  selections  or 
with  ranges  as  selections  can  be  compiled  as  equivalent  if  statements.  Thus  for  our  first  example 
we  may  have: 

if  D in  WORK_DAY  then 
WORK; 
else 
REST; 
end  if; 


3.9  Loop  Statements 


The  main  form  of  loop  statement,  called  a basic  loop,  allows  conditional  or  unconditional  exit 
statements  to  appear  anywhere  within  the  statement  list  of  the  loop; 

loop 

READ_CHARACTER(C); 
exit  when  C = 

PRINT_CHARACTER(C); 

end  loop; 

Although  this  form  of  loop  is  quite  general,  a special  form  also  exists  to  single  out  the  cases  in 
which  a continuation  condition  appears  at  the  start  of  the  loop: 

while  MORE_TO_DO  loop 

end  loop; 

Similarly  two  forms  of  for  loops  are  provided  to  iterate  over  ranges  either  in  normal  (increasing)  or 
in  reverse  (decreasing)  order  (the  range  bounds  must  be  in  increasing  order): 


3-9 


! 

I 


for  I in  1 . 10  loop 


for  J in  reverse  A ..  B loop 
end  loop; 

In  both  cases,  unlike  Pascal,  the  loop  parameter  is  considered  as  local  to  the  loop.  It  is  implicitly 
declared  by  its  appearance  in  the  for  iteration  condition.  Its  value  is  constant  for  each  iteration. 

More  complicated  forms  of  loop  constructs  such  as  Zahn's  construct  (Za  74|  and  the  related  con- 
struct provided  in  Modula  (Wi  761  have  been  considered  in  this  design  but  in  the  end  rejected.  As 
shown  in  the  example  below,  situations  for  which  such  constructs  would  be  used  can  be  written 
quite  easily  with  the  existing  forms. 

declare 

ESCAPE  : (A,  B.  NORMAL)  ;=  NORMAL; 

begin 


for  ...  loop 

ESCAPE  :=  A; 

•xH; 

ESCAPE  :=  B. 

exit; 

ESCAPE  :=  A; 

exit; 

•nd  loop; 

caM  ESCAPE  of 

when  A =>  .. 
whan  B =>  .. 
when  NORMAL 

end; 

The  major  emphasis  in  the  design  of  the  loop  primitives  has  been  on  simplicity:  loop^  should  have 
an  intuitive  meaning  and  users  should  not  have  to  consult  a reference  manual  to  understand  their 
meaning.  Several  studies  on  the  use  of  programming  languages  have  shown  that  the  vast  majority 
of  loops  are  very  simple.  Hence  generalities  such  as  the  step  expression  of  Algol  60  should  be 
avoided.  1 he  redundancy  provided  for  conditional  exits  is  motivated  by  textual  considerations: 
loop  termination  conditions  should  be  marked  very  conspicuously.  Hence 

exit  when  CONDITION: 

is  certainly  more  explicit  than  the  equivalent  form: 

if  CONDITION  then 

exit; 
end  M; 


] 


Guarded  commands  were  also  considered  in  this  analysis  and  not  retained.  They  have  advantages 
for  the  development  of  program  proofs.  However,  they  are  not  compatible  with  other  looping  con- 
structs with  explicit  exits.  Hence  if  they  were  retained  it  would  have  been  to  the  exclusion  of  other 
loop  forms,  a decision  which  seemed  too  drastic. 


I 
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4.  Types 


4. 1 Introduction 


The  notion  of  type  has  gradually  emerged  from  the  past  twenty  years  of  the  history  of  programm- 
ing languages  as  the  way  by  which  we  impose  structure  on  data.  A now  widely  accepted  view  of 
types  is  that  a type  characterizes  the  set  of  values  that  objects  of  the  type  may  assume,  and  the  set 
of  operations  that  may  be  performed  on  them  This  common  view  is  also  taken  in  the  Green 
language  definition. 

There  are  several  important  reasons  for  which  it  is  found  desirable  to  associate  a type  with  cons- 
tants, variables,  and  parameters  of  subprograms: 

• Factorization  of  Properties,  Maintainability 

Knowledge  about  common  properties  of  objects  should  be  collected  in  one  place  and  given  a 
name.  A type  declaration  serves  that  purpose.  Subsequently,  this  type  name  may  be  used  to 
refer  to  these  common  properties  in  object  declarations.  Furthermore,  maintainability  is 
enhanced  since  a change  of  properties  has  only  to  be  effected  at  a single  point  of  the  program 
text,  the  type  declaration. 

• Abstraction,  Hiding  of  Implementation  Details 

Abstract  or  external  properties  of  objects  and  operations  should  be  separated  from  underlying 
and  internal  implementation  dependent  properties  such  as  the  physical  representation  on  a 
specific  machine.  Only  the  abstract  properties  of  an  object  need  to  be  known  for  its  use 
Implementation  details  should  be  hidden  from  the  user.  The  need  for  such  a separation  is  par- 
ticularly strong  in  the  case  of  disjoint  sections  of  a program  text,  produced  and  maintained  by 
different  programmers,  and  possibly  separately  compiled. 

• Reliability 

Objects  with  distinct  properties  should  be  clearly  distinguished  in  a program  and  the  distinc- 
tion should  be  enforced  by  the  translator.  Requiring  that  alt  objects  be  typed  thus  contributes 
to  program  reliability.  Experience  has  shown  that  a well  written  program  in  Pascal  can  be 
recognized  easily  by  the  use  made  of  the  typing  facility  to  increase  the  reliability,  readability 
and  security  of  the  program. 

Several  classical  problems  are  associated  with  the  formulation  of  a type  facility  in  programming 
languages  Some  are  a subject  of  ongoing  debate  among  language  designers  and  users,  in  par- 
ticular: 


(a)  Static  versus  Dynamic  Properties 

Should  both  the  static  properties  (those  which  are  determinable  from  an  analysis  of  the 
program  text  at  translation  time)  and  the  dynamic  properties  (those  which  may  depend  on  the 
dynamic  behavior  of  a program,  such  as  reading  from  an  input  device)  be  covered  by  a sinnle 
notion  of  type? 

(b)  Type  Equivalence 

Should  the  language  provide  some  form  of  equivalence  or  compatibility  among  types  with 
logically  related  properties? 

(c)  Parameterization 

Should  the  language  provide  some  form  of  parameterization  for  types  and  their  associated 
properties?  Should  the  evaluation  of  type  parameters  be  performed  entirely  at  translation 
time  or  be  deferred  until  execution  time? 

The  Green  solutions  to  the  above  problems  are  now  summarized.  A detailed  discussion  of  design 
decisions  is  given  in  later  sections. 

(a)  Static  versus  Dynamic  Properties 

Two  notions  are  distinguished:  the  notion  of  type  and  the  notion  of  subtype.  A type 
characterizes  a distinct  set  of  values  and  its  static  properties,  such  as  the  applicable  opera- 
tions. Constraints  may  be  imposed  on  named  types,  for  example  a range  constraint  for  a scalar 
type  or  an  index  constraint  for  an  array  type.  In  geneial,  these  constraints  cannot  always  be 
determined  at  translation  time. 

A subtype  name  serves  as  an  abbreviation  for  a type  name  and  a constraint  associated  with 
the  type.  Several  difficulties  in  the  types  of  Pascal  noted  by  Habermann  and  others  |Hab  73. 
WSH  7 7 1 are  overcome  in  the  Green  language  by  the  notion  of  subtype. 

(b)  Type  Equivalence 

Each  type  definition  introduces  a distinct  type.  In  consequence,  each  type  name  denotes  a dis- 
tinct type.  Objects  with  distinct  types  cannot  be  intermixed. 

In  contrast,  objects  belonging  to  different  subtypes  of  the  same  type  are  compatible.  They 
may  be  assigned  to  variables  with  differing  subtypes  of  the  same  type.  Constraints  are 
checked  during  translation  whenever  possible  and  during  execution  otherwise. 

Types  defined  as  derived  from  another  type  are  said  to  be  conformable  with  it.  Explicit  conver- 
sions are  possible  between  conformable  types. 

(c)  Parameterization 

Type  definitions  and  their  associated  operations  can  be  encapsulated  in  modules.  A module 
can  be  parameterized  by  a gt  wric  clause  with  the  consequence  thBt  all  contained  definitions, 
including  those  of  types,  are  parameterized.  Generic  modules  must  be  instantiated  at  transla 
tion  time.  Each  instantiation  must  be  explicit;  it  supplies  values  for  the  parameters  and  yields 
new  types. 


4-2 


Parameterization  at  execution  time  is  closely  associated  with  the  notion  of  constraint.  In  particular 
this  applies  to  array  and  record  types: 

• An  array  type  definition  ca  1 leave  index  bounds  unspecified.  These  are  subsequently  specified 
by  an  index  constraint  for  a given  array  object  so  that  different  array  objects  of  the  same  type 
may  have  different  numbers  of  components.  If  such  an  array  is  a formal  parameter  of  a sub 
program,  its  bounds  are  obtained  from  the  actual  parameter  for  each  call. 


• A record  type  may  have  variants,  i.e.  alternative  definitions  of  its  components.  Different 
variants  are  associated  with  the  values  of  a special  component  called  a discriminant,  arid  it  is 
possible  to  constrain  a record  to  a single  variant  by  use  of  a discriminant  constraint.  Variants 
are  otherwise  discriminated  at  execution  time. 

These  solutions  are  detailed  in  the  following  sections.  We  first  introduce  the  notion  of  type  defini 
tions  and  the  resulting  rule  for  determining  if  two  objects  have  the  same  type.  Constraints  and  sub- 
types  are  then  discussed.  Finally  we  discuss  derived  type  definitions. 

The  specific  properties  of  numeric  types  are  discussed  in  Chapter  5,  those  of  access  types  in 
Chapter  6.  Parameterization  with  generic  clauses  is  discussed  in  Chapter  13. 

4.2  Type  definitions 


The  language  provides  the  capability  to  define  new  types.  The  language  construct  used  to 
introduce  a new  type  >s  called  a type  definition.  Examples  of  type  definitions  appear  below. 

range  -2**24  ..  2**24  — integer  type  definition 

(LOW,  MEDIUM,  HIGH)  — enumeration  type  definition 

digits  8 range  0.0  ..  1 E24  — floating  point  type  definition 

delta  0.01  range  0.0  ..  1_000.0  — fixed  point  type  definition 

array  (1  ..  128)  of  CHARACTER  — array  type  definition 

record  RE.  IM  : INTEGER:  end  record  — record  type  definition 

,iew  INTEGER  --  derived  type  definition 

access  STRING  — access  type  definition 

As  stated  before,  one  of  the  objectives  of  a type  system  is  reliability.  It  should  prevent  erroneous 
mixing  of  objects  of  different  types.  Hence  a key  issue  in  the  design  of  a type  system  is  the  for- 
mulation of  the  conditions  that  must  be  satisfied  by  two  variables  (or  constants)  in  order  that  they 
should  have  the  same  type. 

Alternative  solutions  for  the  issue  of  type  equivalence  have  been  formulated  in  a paper  by  Welsh  et 
al.  |WSH  7 7 1 . These  solutions  are  classified  into  two  families  called  name  equivalence  and  struc- 
tural equivalence. 

The  solution  used  in  the  Green  language  is  related  to  name  equivalence.  It  is  based  on  the  principle 
that  every  type  definition  introduces  a distinct  type  Two  type  definitions  introduce  two  distinct 
types  even  if  they  are  textually  identical  For  example,  the  objects  A and  B declared  by 

A : (ON,  OFF): 

B : (ON.  OFF): 

belong  to  two  distinct  types  since  they  are  declared  in  terms  of  two  distinct  type  definitions  On 
the  other  hand  the  objects  C and  0 declared  by 
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C.  D (LOW  MEDIUM  HIGH); 


belong  to  tho  same  typo  sinew  they  are  declared  in  terms  of  a single  type  definition. 

Type  definitions  given  directly  in  object  declarations  as  in  the  above  examples  are  allowed  and  are 
called  anonymous  type  definitions.  They  are  sometimes  useful  foi  defining  the  typo  of  some  record 
components 

In  the  majority  of  cases  however  a type  definition  is  givon  a name  in  the  type  declaration  where  it 
appears  A consequence  of  the  principle  stated  above  is  that  two  distinct  type  names  always  refer 
to  two  distinct  types.  Thereafter  two  objects  have  the  same  type  if  they  refer  to  tho  same  type 
name  in  their  declaration  The  expression  name  equivalence  derives  from  the  fact  that  this  is  by  far 
the  most  usual  way  for  two  objects  to  have  the  same  type.  As  an  example  consider 

type  PERSON  Is 

record 

SEX  constsnt(MALE  FEMALE); 
cate  SEX  of 

when  MALE  > ENLISTED  BOOLEAN, 

when  FEMALE  n PREGNANT  BOOLEAN 

end  caee. 
end  record 

X PERSON 
V PERSON 

The  varieties  X and  V both  belong  to  the  same  type  since  they  both  re-far  to  the  same  type  name 
(PERSON)  in  their  declaration  (note  that  the  selected  components  X.SEX  and  Y.SEX  belong  to  the 
same  anonymous  type) 

Structural  equ  valence  refers  to  solutions  where  some  form  of  equivalence  rule  is  formulated 
between  types  on  tho  basis  of  their  properties.  We  have  rejected  structural  equivalence  in  order  to 
avoid  pattern  matching  problems  for  the  translator  and  for  the  human  reader.  We  also  believe  that 
structural  equivalence  tends  to  defeat  the  purpose  of  strong  typing  since  objects  may  bo  con 
sidered  as  being  of  the  same  typo  because  their  structures  are  identical  by  accident  or  because 
they  have  become  identical  as  a result  of  textual  modifications  performed  during  program 
maintenance.  Such  objects  can  then  be  mixed  erroneously  without  causing  translator  diagnostics 

Further  argument;;  in  favor  of  name  equivalence  ore  presented  in  later  sections. 


4.2.1  Scalar  and  Access  Types 


Scalar  types  cover  enumeration  types  integer  and  real  types. 

Enumeration  tvpos  are  defined  try  enumeration  of  their  values.  These  are  considered  to  be  in 
increasing  order.  The  same  litoral  may  appear  in  more  than  one  enumeration  type.  This  is  a logical 
consequence  of  the  fact  that  character  sots  con  ho  defined  as  enumeration  types.  Tt  would  not  be 
acceptable  for  example  to  require  the  character  A”  to  appear  exclusively  in  one  character  sot 
Enumeration  literals  that  may  denote  enumeration  values  of  different  types  are  said  to  be 
overloader'  As  an  example  consider 


type  COLOR  is  (RED,  ORANGE,  YELLOW.  GREEN,  BLUE,  VIOLET); 
type  LIGHT  is  (RED,  AMBER,  GREEN); 


As  the  enumeration  value  GREEN  appears  in  two  types,  it  may  be  necessary  to  qualify  GREEN  by 
the  desired  type  in  some  contexts,  for  example  COLOR(GREEN)  or  LIGHT(GREEN). 

Structural  equivalence  of  enumeration  types  is  undesirable  since  it  may  involve  comparisons  of 
long  identifier  lists.  Furthermore,  the  usual  maintenance  problem  would  exist,  since  two  enumera 
tion  types  could  accidentally  become  equivalent  by  inserting  or  deleting  an  element. 

The  maintenance  argument  is  similar  for  numeric  types.  Two  real  types  should  not  be  equivalent 
just  because  their  6rror  bound  specifications  happen  to  be  the  same.  The  programmer  should  be 
encouraged  not  to  use  just  FLOAT  or  LONG_FLOAT  as  the  type  of  the  variables,  but  to  introduce 
the  particular  precisions  required  for  the  applications  and  to  express  the  commonality  by  a type 
declaration. 

An  access  type  definition  introduces  a distinct  collection  of  dynamic  objects.  The  space  for  that 
collection  can  be  released  once  the  scope  of  the  access  type  definition  is  left,  since  different  collec- 
tions are  associated  with  different  access  types.  Using  structural  equivalence  for  access  types 
would  introduce  a difficulty  since  two  structurally  equivalent  access  types  could  appear  in  different 
scopes. 


4.2.2  Record  type* 


To  emphasize  the  arguments  against  structural  type  equivalence  rules,  we  next  discuss  record 
types.  Consider,  for  example: 

type  COMPLEX  la 
record 

RE  : INTEGER. 

IM  • INTEGER; 

end  record. 

type  RATIONAL  it 
record 

NUMERATOR  : INTEGER; 

DENOMINATOR  : INTEGER  range  1 . INTEGER  LAST 

end  record 

Several  alternative  forms  of  structural  equivalence  rules  can  be  considered,  involving  increasing 
amounts  of  checking,  especially  if  the  record  types  have  a large  number  of  components: 

(a)  two  types  are  equivalent  if  the  texts  in  the  right-hand  side  of  their  declarations  (after  rs)  are 
idontical  (disregarding  textual  layout  such  as  space  or  new  line  characters,  etc.); 

(b)  two  typ  s are  equivalent  if  their  component  names  and  the  type  names  of  their  components 
agree,  in  the  same  order; 

(c)  same  as  (b)  but  the  names  of  the  components  need  not  agree,  only  their  order  This  is  a more 
mathematical  point  of  view,  where  one  considers  a record  as  a cartesian  product; 
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(d)  same  as  (h)  but  the  order  of  components  is  not  significant; 

(e)  same  as  lb)  but  only  the  type  names  of  the  corresponding  components  must  be  the  same,  not 
the  names  of  the  components  nor  the  constraints; 

(f)  same  as  (e)  but  the  subtypes  must  be  equivalent; 

(q)  same  as  (e)  but  the  component  types  must  be  equivalent,  while  their  names  need  not  be  iden- 
tical; 

(h)  same  as  (g)  but  a type  name  is  also  equivalent  to  the  (possibly  anonymous)  text  of  the  right- 
hand  side  of  its  declaration. 

The  types  COMPLEX  and  RATIONAL  given  above  would  be  equivalent  under  alt  the  rules  if  their 
component  names  were  accidentally  the  same  and  if  the  constraint  on  DENOMINATOR  were  not 
expressed  in  the  type  declaration.  More  specifically,  under  rule  (b).  COMPLEX  would  be  equivalent 
to 


type  ANOTHER_COMPLEX  it 

record 

RE,  IM  : INTEGER; 

end  record: 

Rule  (c)  makes  sense  for  a language  with  positional  notation  only.  It  complicates  the  checking  by 
the  compiler,  since  all  permutations  must  be  considered.  Conversely,  rule  (d)  is  sensible  for  a total- 
ly non-positional  language  where  component  names  must  always  be  specified  for  record 
aggregates.  Rule  (e)  complicates  the  implementation  of  constraints  and  subtypes  for  components, 
since  they  must  be  checked  for  each  component  on  record  or  array  assignments.  Rule  (f)  cannot  be 
checked  statically.  Rule  (g)  requires  a recursive  matching  algorithm.  In  addition,  rule  (h)  requires 
type  expansion  and  even  an  algorithm  of  cycle  reduction  in  the  case  of  mutually  recursive  access 
types. 

All  these  complexities  for  the  implementation  and.  above  all.  for  the  user,  are  avoided  in  Green  by 
adopting  the  simple  rule  that  every  type  definition  introduces  a distinct  type. 


4.2.3  Array  Types 


Arguments  similar  to  those  against  the  structural  equivalence  of  record  types  hold  for  array  types. 
It  is  certainly  desirable  to  distinguish  between  arrays  whose  component  type  >s  different;  the 
insistence  that  even  their  component  subtypes  be  the  same  is  well  motivated  by  efficiency  con- 
siderations Consider,  for  example: 

type  LINE  it  array  <1  128)  of  CHARACTER. 

type  TEXT_LINE  it  array  (1  128)  of  CHARACTER  ranga  "A"  ..  "Z"; 

Assignment  of  an  array  of  type  LINE  to  an  array  of  type  TEXT_LINE  requires  an  imp'^cit  loop  to 
check  the  range  constraint  for  each  component  individually.  An  explicit  conversion  is  required, 
which  informs  the  reader  of  this  potential  cost  (the  absence  of  implicit  conversion  follows  from  the 
general  rules  of  the  language;  the  possibility  of  an  explicit  conversion  follows  from  the  rule 
explained  in  section  4,5  below). 
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One  should  also  distinguish  between  arrays  with  distinct  index  types,  even  if  their  component  type 
is  the  same: 

type  OPTION_SET  is  array  (OPTION'FIRST  ..  OPTION  LAST)  of  BOOLEAN: 
type  COLOR_SET  is  array  (COLOR'FIRST  COLOR'LAST)  of  BOOLEAN; 

An  array  of  type  OPTION_SET  should  not  be  compatible  with  one  of  type  COLOR_SET  just 
because  the  number  of  options  happens  to  be  the  same  as  the  number  of  colors.  From  a concep- 
tual point  of  view,  the  two  array  types  have  nothing  to  do  with  each  other,  apart  from  their  com- 
mon component  type. 

On  the  other  hand,  it  is  reasonable  to  establish  a relationship  between  arrays  that  differ  only  in 
their  index  ranges,  as  long  as  their  index  types  and  component  types  are  the  same.  As  shown  in 
section  4.3  below,  this  relationship  can  be  expressed  by  using  array  subtypes. 

To  summarize,  the  rule  that  two  type  definitions  always  introduce  two  distinct  types  is  applied 
uniformly  to  all  type  definitions.  As  a consequence  two  distinct  type  names  always  refer  to  two 
distinct  types.  Commonality  of  properties  is  expressed  in  general  by  using  the  same  type  name. 


4.3  Constraints  and  Subtypes 


As  mentioned  before,  a type  characterizes  a set  of  values  that  objects  of  the  type  may  assume  and 
a set  of  operations  applicable  to  those  values.  Membership  of  an  object  in  a type  is  a static 
property  resulting  directly  from  the  declaration  of  the  object. 

It  is  possible  to  restrict  the  set  of  allowed  values  of  a type  without  changing  the  set  of  applicable 
operations.  Such  a restriction  is  called  a constraint,  and  the  subset  of  values  it  defines  is  called  a 
subtype.  Membership  of  an  object  in  a subtype  can  result  from  the  object  declarations.  However, 
this  need  not  always  be  the  case  since  it  is  possible  to  define  several  overlapping  subtypes  (named 
or  not)  of  a given  type.  Membership  in  a subtype  mav  or  may  not  be  determined  statically. 


4.3.1  Constraints 


A constraint  can  be  used  to  restrict  the  set  of  allowable  values  of  a type  as  in  the  followinq  exam- 
ple: 


CHARACTER  range  "A"  ..  "Z" 

Such  constraints  may  effectively  be  used  by  the  compiler  for  optimization  purposes.  Their  major 
use,  however,  is  for  greater  security  in  assignment.  Violations  are  reported  at  translation  time 
when  possible,  or  at  execution  time  by  raising  an  appropriate  exception. 
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Consider  the  following  example: 

declare 

subtype  LETTER  is  CHARACTER  range  "A" 

subtype  HEX_LETTER  is  LETTER  range  “A" 

subtype  EFG_LETTER  is  LETTER  range  "E" 


CHARACTER 

LETTER 

HEX_LETTER 

EFG_LETTER 


:=  "X"; 
:=  "Y"; 
= "F"; 
= "E"; 


— no  check  necessar/ 

— no  check  necessary 

--  check  that  (A  in  LETTER),  i.e. 

check  that  ILETTERFIRST  <=  A)  and  (A  <=  LETTER  LAST) 
" check  that  (D  <=  HEX_LETTER’LAST) 

--  check  that  (EFG_LETTER  FIRST  <=  C) 


4.3.2  Subtypes 


sr  - rsr  .r  r trsw -%r — a - 

subtype  LETTER  is  CHARACTER  range  "A"  "Z" 


subtype  FIFTEEN.FIRST  i,  LETTER  rang.  -A”  ..  -(T:  - incorrect! 


Thecharacter  'O’  too),  given  bv  mistake  instead  of  the  latte,  -O',  does  no,  belong  to  the  sobtype 


4.3.3  Evaluation  of  Constraints 


could  not  be  used  as  general  loop  iterators  and  a^yg^ff'XTlSf  ra"96S 
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An  issue  to  be  considered  <6  the  time  at  which  the  expressions  appearing  in  constraints  should  be 
evaluated  Consider  the  subtype  declaration: 

subtype  S is  T range  U ..  V; 

where  U and  V may  be  arbitrary  expressions.  The  rule  adopted  in  the  Green  language  definition  is 
that  such  expressions  are  evaluated  when  the  subtypo  declaration  is  elaborated  This  means  that 
the  subtype  declaration  is  equivalent  to  the  following  sequence 

U 0 : constant  T :=  U; 

VO  : constant  T :=  V; 
subtype  S is  T range  (JO  ..  V O: 

where  (JO  and  V._0  represent  identifiers  not  used  elsewhere.  Note  that  if  the  bounds  of  the  range 
are  not  known  at  translation  time,  a descriptor  (containing  the  values  of  U 0 and  V O)  must  be 
implicitly  generated  by  the  compiler.  Hence,  for  efficiency  reasons,  it  is  important  to  isolate  the 
knowledge  about  equivalent  constraints  into  one  subtype  declaration  and  to  use  the  name  of  this 
subtype  instead  of  repeating  the  constraint  in  several  variable  declarations.  The  values  of  the 
implicit  constants  (J  O and  V .0  are  denoted  by  the  subtype  attributes  S'FIRST  and  S LAST. 

Note  also  that,  for  reliability  and  maintainability,  using  a subtype  such  as  S is  far  better  than 
repeating  the  corresponding  constraint  (range  U ..  V)  at  various  points  of  the  text,  since  the  values 
of  U and  V at  these  points  might  differ.  Thus  it  is  preferable  to  write 

declare 

subtype  S is  T range  U ..  V; 

X : S' 

A : array  (S'FIRST  ..  S'LAST)  of  T; 

procedure  P (Z  : S)  is  ...  end  P; 
begin 

for  I in  S'FIRST  ..  S'LAST  loop 
if  A(l)  in  S'FIRST  ..  S'LAST  then 

end  if; 
end  loop; 
end; 

rather  than  to  repeat  the  corresponding  range  in  terms  of  the  defining  expressions  U and  x/  at 
various  points  of  the  text. 

The  rule  that  constraints  are  evaluated  when  the  declaration  where  they  are  given  is  elaborated,  is 
applied  uniformly  in  all  cases.  In  particular  it  applies  to  constraints  of  subprogram  parameters. 
Making  an  exception  for  this  case  would  increase  the  complexity  of  the  language  and  also  of  the 
implementation  since  a subtype  description  would  have  to  be  maintained  for  every  subprogram 
call  (not  just  one  for  the  subprogram  declaration)  because  of  the  possibility  of  recursion.  For  these 
reasons  the  simpler,  uniform  rule  has  been  retained. 


4.3.4  Record  Variants 


r 


A record  type  with  a variant  part  specifies  several  alternative  variants  of  the  type.  This  means  that 
the  set  of  possible  record  values  is  the  union  of  the  sets  of  values  possible  for  the  alternative 
variants.  Seen  in  this  light,  a variant  of  a record  type  is  a subtype  of  the  record  type. 

A variant  part  depends  on  a special  component  of  the  record,  called  its  discriminant.  Each  variant 
defines  the  components  that  exist  for  a specific  value  of  the  discriminant.  This  is  thus  a form  of 
parameterization  of  record  types.  However,  unlike  the  parameterization  that  can  be  achieved  by 
the  generic  facility  this  parameterization  can  be  dynamic:  it  can  depend  on  the  value  of  the  dis- 
criminant and  this  value  need  not  be  known  statically  (at  translation  time). 

When  declaring  a record  variable  it  is  possible  to  specify  that  its  discriminant  must  always  have  a 
given  value.  This  specification  is  a discriminant  constraint  that  restricts  the  set  of  possible  record 
values  *o  those  of  the  designated  variant.  The  translator  may  take  advantage  of  this  knowledge 
when  setting  the  amount  of  space  reserved  for  the  record  variable.  We  may  also  define  a subtype 
of  a record  type  by  associating  the  discriminant  constraint  with  the  record  type  name.  We  illustrate 
these  possibilities  with  the  following  example: 


declare 

type  PERSON  is 
record 

BIRTH  : DATE; 

SEX  : constant!  MF):  — discriminant 

case  SEX  of 

when  M > ENLISTED  : BOOLEAN: 
when  F =>  PREGNANT  : BOOLEAN: 

end  case, 
end  record: 


subtype  MALE  is  PERSONISEX  =>  M): 
subtype  FEMALE  is  PERSONISEX  =>  F): 


ANYONE 

HE 

PETER 

JOAN 

SHE 

begin 


PERSON; 

MALE; 

PERSON(M): 

FEMALE; 

FEMALE; 


ANYONE  ;=  HE: 


ANYONE  :=  JOAN; 

HE  :=  PETER; 

HE  :=  JOAN; 


SHE  : ANYONE; 


Equivalent  methods  of 
declaring  males 


— Valid,  no  checking  required  since  MALE 

— is  a subtype  of  PERSON 

— Similarly  no  check  needed 

— No  check  needed,  both  are  males 

— Translation  time  error  since  MALE  and  FEMALE 

— are  disjoint  subtypes  of  PERSON 

— Execution  time  check  necessary:  it  will 

— raise  an  exception  if  ANYONE  is  not  a female 


SHE  :=  FEMALE(ANYONE): 

end: 


— Equivalent  to  above,  but  useful  redundancy 

— to  emphasize  the  possible  exception  condition 
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When  accessing  a component  of  a constrained  record  such  as  JOAN'  or  PETER,  the  value  of  its  dis- 
criminant and  hence  the  associated  variant  is  already  known.  The  constraint  is  part  of  the  static 
information  known  about  such  record,  and  any  assignment  to  the  record  variable  is  checked  with 
respect  to  the  constraint  either  at  translation  or  at  execution  time.  Consequently  references  to 
record  components  such  as  JOAN. PREGNANT  or  PETER. ENLISTED  are  perfectly  secure 

When  accessing  a component  of  a record  that  is  declared  without  a constraint  such  as  ANYONE 
more  precautions  should  be  taken.  A part  of  this  security  derives  from  the  fact  that  discriminants 
are  deferred  constants  and  are  not  directly  assignable.  They  may  be  set  when  the  record  value  is 
defined  and  may  only  be  changed  by  assignment  to  the  record  as  a whole  Thus 

ANYONE  :=  PERSONIBIRTH  =>  1940,  SEX  =>  M,  ENLISTED  = n TRUE); 

is  a legal  complete  record  assignment  which  sets  SEX  equal  to  M.  Similarly,  assignments  such  as 
ANYONE  JOAN;  or  ANYONE  ;=  PETER;  are  complete  record  assignments  which  consequently 
set  the  value  of  the  discriminant.  However  we  must  consider  such  a complete  record  assignment 
as  defining  a new  object  and  the  value  of  the  object  s discriminant  cannot  be  changed  separately 
Thus  an  assignment  such  as 

ANYONE. SEX  :=  F;  - Illegal  I 

is  forbidden  and  will  be  rejected  by  the  translator. 

The  second  key  element  to  the  security  of  variants  is  that  access  to  a component  of  a variant  is 
only  legal  if  the  discriminant  has  the  corresponding  value.  This  means  that  an  access  to  the  com 
ponent 


...  ANYONE. ENLISTED  ... 

is  equivalent  to  the  following  text. 

if  ANYONE. SEX  /=  M then 
raise  DISCRIM INANT_ERROR; 
end  if; 

...  ANYONE. ENLISTED 

Naturally  the  compiler  can  omit  this  implicit  discriminant  check  in  contexts  where  explicit  checks 
are  made,  or  when  the  explicit  constraints  make  such  checks  unnecessary.  Such  explicit  dis- 
crimination may  take  several  forms.  It  can  be  achieved  by  an  assertion  or  a renaminq  declaration 
specifying  a subtype.  It  can  also  be  achieved  by  an  if  statement 

if  ANYONE. SEX  = M then 

— access  to  ANYONE. ENLISTED  requires  no  implicit  check 

end  if: 

or  similarly  by  a case  statement 

case  ANYONE. SEX  of 
whe.i  M => 

— access  to  ANYONE. ENLISTED  requires  no  check 

whan  F => 

— access  to  ANYONE  PREGNANT  requires  no  check 

end  case; 
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Of  course,  the  check  can  only  be  omitted  as  long  as  the  discriminant  is  not  changed  as  a result  of  a 
complete  record  assignment.  Consider  for  example: 


cate  ANYONE. SEX  of 
whan  M => 

...  ANYONE. ENLISTED  ...  — occurrence  1 
...  ANYONE. ENLISTED  ...  — occurrence  2 
UPDATE(ANYONE); 

...  ANYONE. ENLISTED  ...  --  occurrence  3 

PRINT(ANYONE); 

...  ANYONE. ENLISTED  ...  — occurrence  4 

whan  F=>  ... 

end  case; 

No  checks  are  needed  for  the  first  two  occurrences.  A check  is  needed  for  the  third  (assuming  the 
mode  of  the  parameter  of  UPDATE  to  be  in  out)  but  no  check  is  needed  for  the  fourth  occurrence 
(assuming  the  mode  of  the  parameter  of  PRINT  to  be  in). 

Note  that  additional  problems  exist  if  a record  is  shared  by  two  tasks.  One  task  could  perform  a 
complete  record  assignment  (thereby  changing  the  discriminant)  while  another  is  reading  a com- 
ponent. We  consider  this  problem  to  be  a danger  inherent  in  the  use  of  shared  variables  rather  than 
a problem  concerning  the  formulation  of  record  types.  The  tasking  facilities  of  the  language  are 
powerful  enough  to  make  such  shared  variables  virtually  useless.  If  they  are  nevertheless  used,  the 
appropriate  precautions  should  be  taken  by  the  programmer.  On  the  other  hand,  we  did  not  believe 
it  correct  to  disfigure  the  semantics  of  the  language  because  of  such  possible  misuse. 

It  might  be  felt  that  the  checking  code  is  a high  price  to  pay.  This  is,  however,  essential  for  security 
with  variant  records.  Previous  experience  with  languages  such  as  Simula,  which  force  a similar  dis- 
crimination of  variants,  show  that  these  checks  are  not  as  frequent  as  one  might  suppose.  The 
parts  of  the  programs  that  operate  on  a given  variant  tend  to  be  textually  discriminated  as  well  as 
dynamically  discriminated.  Hence  the  checks  can  be  achieved  at  a rather  low  cost  (see  also  (We 
78|). 

One  should  not  underestimate  the  importance  of  secure  access  to  components  of  a variant  part.  A 
recent  experiment  |Ha  7 7 J with  a Pascal  compiler  in  which  this  facility  was  offered  as  an  extension 
reported  that  these  checks  caught  a quarter  of  the  initial  enors  in  a large  program 


4.3.5  Array  Types  with  Unspecified  Bounds 

An  array  type  declaration  must  specify  the  type  of  the  array  components  and  the  type  of  each 
index,  hut  it  need  not  specify  the  actual  bounds  of  each  index  This  means  thUi  the  set  of  possible 
array  values  defined  by  the  type  contains  arrays  with  different  numbers  of  components.  Consider 
for  example: 

subtype  NATURAL  is  INTEGER  range  1 . INTEGERLAST; 

type  STRING  is  array(NATURAL)  of  CHARACTER; 

Values  of  the  type  STRING  are  arrays  of  components  of  type  CHARACTER  indexed  by  natural 
numbers.  However  different  string  values  need  not  have  the  same  index  bounds  and  hence  the 
same  number  of  characters. 
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It  is  possible  to  partition  the  set  of  array  values  into  subsets  corresponding  to  some  fixed  index 
bounds.  Each  such  subset  defines  a subtype  of  the  array  type.  The  constraint  used  to  fix  the  range 
of  values  of  a given  index  is  called  an  index  constraint.  For  example 

BUFFER  : STRING!  1 ..  1000); 

defines  an  array  object  of  type  STRING  whose  index  lower  and  upper  bounds  are  the  natural 
numbers  1 and  1 0C0.  As  usual  we  can  also  define  a subtype  by  naming  the  association  of  the  type 
name  with  the  index  constraint: 

subtype  LINE  is  STRING!  1 ..  120); 

HEAD_LINE  : LINE; 

BLANK_LINE  : constant  LINE  :=  (LINEFIRST  . LINELAST  =>  " “); 

Note  that  the  other  form  of  array  type  declaration  (where  the  bounds  are  directly  specified)  is  in 

fact  a special  case  where  the  index  constraint  is  directly  given  with  the  array  type  declaration.  Thus 
the  type  declaration 

type  SCHEDULE  is  array  (DAY  FIRST  . DAY' LAST'  of  BOOLEAN; 
can  be  view*  1 as  a contraction  of 

type  schedule  is  array  (DAY)  of  BOOLEAN;  - irbitrary  number  of  days 

subtype  SCHEDULE  is  sc/»edu/e(DAY’FlRST  ..  DAY'LAST);  --  always  7 days 

For  any  object  of  an  array  type,  the  bounds  of  each  index  must  be  known.  We  have  seen  that  they 

can  be  specified  by  an  index  constraint;  they  can  also  be  obtained  from  the  initial  value- 

TITLE  : STRING  :=  HEADLINE; 

MESSAGE  : constant  STRING  :=  'HOW  MANY  CHARACTERS?”; 

Similarly,  for  a formal  parameter  they  can  be  obtained  from  those  of  the  corresponding  actual 
parameter.  Thus  a subprogram  with  a parameter  of  such  a type  applies  to  c'l  arrays  of  the  type 
independently  of  their  index  bounds  (unless  of  course  an  index  constraint  is  given  for  the 
parameter  declaration).  For  example  concatenation  for  a string  of  arbitrary  length  is  defined  as 

function  -&"(X,Y  : STRING)  return  STRING  is 
RESULT  : STRING!  1 ..  X'LENGTH  + Y'LENGTH); 

begin 

RESULT!  1 ..  X’LENGTH)  :=  X; 

RESULT(X'LENGTH  + 1 ..  RESULTLAST)  :=  Y; 
return  RESULT; 
end 

This  last  example  shows  that  array  ypes  with  unspecified  bounds  can  be  viewed  as  a form  of  type 
parameterization.  Again,  unlike  the  parameterization  that  can  be  achieved  by  generic  clauses 
(which  is  purely  at  translation  time),  this  parameterization  can  be  dynamic.  For  example,  the 
bounds  of  the  strings  can  vary  from  call  to  call.  Such  array  types  do  not  introduce  new  implemen- 
tation problems  since  descriptors  for  index  constraints  are  needed  in  any  case  whenever  the 
bounds  of  an  array  are  not  known  at  translation  time. 
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4.4  Derived  Type  Definitions 


The  basic  mechanisms  for  introducing  a new  type  are  by  enumeration  and  by  composition  from 
existing  ones,  in  typo  definitions.  Certain  basic  characteristics  are  automatically  acquired  by  such  a 
type,  for  example  the  availability  of  literals,  aggregates,  and  operations  such  as  indexing,  compo- 
nent selection,  etc.  Another  way  of  introducing  a type  is  by  means  of  a private  type  declaration 
(see  8 3.3). 

A third  possibility  is  provided  in  the  Green  language  A type  8 is  declared  as  deriving  its 
characteristics  from  those  of  another  existing  type  A if  it  is  declared  as 

type  B is  new  A 

This  form  of  type  declaration  is  very  useful  whenever  a type  B is  to  have  the  same  characteristics 
as  a type  A and  possibly  some  additional  ones.  All  operations  available  for  obiects  of  type  A at  the 
point  of  declaration  of  B are  inherited  by  B.  although  A and  B nevertheless  remain  distinct  types. 
Conversions  between  the  two  types  are  possible  but  they  must  be  explicit,  and  must  use  the  type 
name  as  qualification. 

The  relationship  of  derivation  established  by  derived  type  declarations  is  transitive  but  not  sym- 
metric. For  example  in 

type  C is  new  B: 
type  D is  new  A 

the  type  C implicitly  derives  all  characteristics  of  A through  B.  Similarly  D derives  all  its 
characteristics  from  those  of  A but  no  direct  explicit  conversion  is  possible  between  C and  D. 
Conversions  must  be  achieved  indirectly  step  by  step,  via  the  common  ancestor  A.  The  relation  can 
thus  be  depicted  as  a strict  hierarchy. 

For  example,  consider 

type  STRING  is  array  (NATURAL)  of  CHARACTER; 

type  LINE  is  now  STRING!  1 ..  160): 

type  CARD  is  naw  STRING!  1 . 80); 

type  CONTROL-CARD  is  new  CARD: 

type  PROGRAM_CARD  is  new  CARD: 

type  DATA_CARD  is  new  CARD; 

Objects  of  type  LINE  cannot  be  accidentally  mixed  with  those  of  type  CARD,  However,  they  can 
both  be  converted  to  objects  of  type  STRING  (of  appropriate  length)  by  means  of  explicit  conver- 
sions. Similarly,  CONTROI — CARD.  PROGRAM_CARD,  and  DATA_CARD  are  distinct  descendants 
of  CARD. 

Derived  type  definitions  are  useful  for  the  definition  of  numeric  types,  for  example  when  a user 
introduces  a type  such  as 

type  MYLREAL  is  new  FLOAT 
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This  type  inherits  all  operations  that  are  so  far  available  for  the  type  FLOAT  If  for  example  a func 
tion  SORT  defined  as 


function  SQRTIX  . FLOAT)  return  FLOAT. 

is  available,  the  effect  of  the  derived  type  definition  is  to  produce  a function  equivalent  to  the  one 
defined  by 


function  SQRTIX  : MY_FLOAT)  return  MY_FLOAT; 

Note  that  if  it  were  not  possible  to  inherit  such  library  functions  conveniently,  the  user  might  be 
tempted  to  work  with  the  predefined  types.  This  would  endanger  portability  since  the  latter  are 

implementation  dependent. 

if  a constraint  is  oiven  in  the  derived  type  definition,  it  does  not  affect  the  operations  and  values 
that  are  inherited  but  must  be  interpreted  as  applying  to  all  objects  of  the  declared  type.  Hence  the 

declaration 


type  MYJNT  is  new  INTEGER  range  1 1000, 

can  be  viewed  as  equivalent  to 

type  my  int  is  new  INTEGER; 

subtype  MYJNT  is  my  int  range  1 ..  1000, 

One  consequence  of  this  definition  is  that  for  I of  type  MYJNT  the  relation 


I < 2000 

is  legal  since  the  value  2000  is  inherited  from  the  type  INTEGER,  and  the  relation  is  of  course 
TRUE  since  I must  be  in  the  range  1 ..  1000. 

Floating  point  and  integer  type  definitions  are  interpreted  in  terms  of  derived  type  definitions.  Thus 
a floating  point  type  definition  such  as 


type  MY_REAL  is  digits 


10; 


is  mapped  by  the  compiler  as  an  appropriate  predefined  floating  point  type  (say  FLOAT  in  this 
case)  with  sufficient  precision.  Hence  it  is  equivalent  to  the  following  declaration 


type  MY_REAL  is  new  FLOAT  digits  10; 


4.5  Explicit  Conversions  Between  Array  Types 


The  idea  of  name  equivalence  (rather  than  structural  equivalence)  has  been  used  systematically  in 
Ihis  design;  in  particular  it  has  been  used  for  array  type  definitions.  Remember  that  aside  from 
simplicity  one  of  the  main  arguments  in  favor  of  name  equivalence  is  the  need  to  avoid  accidental 
type  equivalence.  On  the  other  hand  this  argument  does  not  apply  for  explicit  conversions;  being 
explicit  they  are  unequivocally  intentional  and  cannot  be  accidental 

Explicit  type  conversions  are  clearly  desirable  among  array  types  satisfying  certain  concHtions.  To 
illustrate  their  need  consider  first  a package  defining  sorting  operations  It  could  appear 
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package  SORTING  it 

type  VECTOR  is  array  (INTEGER)  of  REAL; 
procedure  SORT(X  : in  out  VECTOR); 

end  SORTING; 

Similarly  a package  for  performing  listing  of  arrays  could  be  specified  as 
package  LISTING  is 

type  TABLE  is  array  (INTEGER)  of  REAL; 
procedure  LIST(X  : in  TABLE); 

end  LISTING; 

These  two  packages  are  of  general  use  and  hence  they  would  probably  be  made  available  as 
library  packages.  A user  trying  to  perform  both  sort  operations  (the  operations  of  the  type  VEC- 
TOR) and  listing  operations  (the  operations  of  the  type  TABLE)  would  be  faced  with  a contradiction 
if  explicit  type  conversions  were  not  available  since  any  declared  array  can  only  be  of  one  type.  In 
addition  a user  may  have  declared  an  array  as 

A : array  (1  ..  1000)  of  REAL; 

without  knowing  in  advance  that  he  would  ever  sort  (or  list)  such  arrays.  It  would  be  undesirable  to 
have  to  modify  the  declaration  of  A because  the  array  needs  to  be  sorted  in  one  part  of  this 
program. 

For  these  reasons  explicit  conversions  are  permitted  between  two  array  types  (named  or  not)  if  the 
index  types  for  each  dimension  are  the  same  (or  derived  from  each  other)  and  if  the  component 
types  are  the  same  (or  derived  from  each  other).  Such  explicit  conversions  are  expressed  as 
qualified  expressions.  Thus  our  example  above  can  appear  as 

declare 

use  SORTING.  LISTING; 

A : array  (1  ..  1000)  of  REAL; 

begin 

SORT  (VECTOR(A)); 

LIST(TABLE(A)); 

end; 

Note  that  conversions  are  also  possible  when  the  constraints  on  the  component  type  are  different. 
Consider  for  example  the  array  types 

type  CHARJJNE  is  array  (1  ..  120)  of  CHARACTER; 

type  TEXT_LINE  is  array  (1  ..  120)  of  CHARACTER  range  "A"  "Z"; 

CL  : CHAR_LINE; 

TL  : TEXTJJNE; 

Explicit  conversions  such  as 

CL  :=  CHARJJNE  (TL); 

TL  :=  TEXT_LINE  (CL); 
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are  allowed.  The  fact  that  they  are  explicit  warns  the  user  that  they  may  (but  need  not)  be  costly. 
For  in  out  parameters  implemented  by  reference,  such  conversions  may  require  the  creation  of  a 
copy  on  the  calling  side  if  the  compiler  has  chosen  different  representations  for  the  two  types. 


4.6  Conclusion  on  Type  Parameterization 


In  the  design  of  the  Green  language  we  have  very  carefully  introduced  a distinction  between 
parameterization  at  translation  time  and  at  execution  time,  especially  in  the  case  of  types. 

Parameterization  at  translation  time  is  achieved  by  the  generic  facility  (see  Chapter  13).  Tne  basis 
for  this  facility  is  quite  traditional.  It  is  context  dependent  macro  substitution.  Hence  it  can  be  used 
very  freely,  and  it  can  be  implemented  efficiently. 

For  parameterization  at  execution  time  this  design  has  chosen  to  remain  extremely  conservative, 
and  to  provide  this  only  in  domains  in  which  it  is  already  traditional,  such  as  variant  records  and 
array  types. 

On  the  other  hand  we  consider  the  problems  of  complete  parameterization  at  execution  time  to  be 
a subject  of  current  research  (see  IHW  79|jBJ  78)).  To  the  best  of  our  knowledge,  solutions  to  this 
problem  are  not  available,  unless  one  is  willing  to  abandon  all  efficiency  considerations  and 
interpret  type  parameters  at  e cution  time.  Others  may  yet  show  that  solutions  do  exist  with 
efficient  implementation,  and  that  we  were  too  cautious. 
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5.  Numeric  Types 


5.1  Introduction 


From  the  earliost  days  of  computing,  numerical  calculations  have  played  a dominant  role  in  the  use 
of  computers.  The  need  for  a method  of  representing  numbers  that  would  rapidly  handle  a wide 
range  of  values,  even  if  the  representation  were  approximate,  resulted  in  floating  point  hardware  in 
the  second  generation  of  machines.  Despite  the  long  history  of  numeric  computation,  the  majority 
of  programming  languages  have  obvious  defects  in  their  handling  of  both  fixed  point  and  floating 
point  data  types. 

Fortran  is  very  widely  used  for  scientific  computation  and  compilers  are  available  on  almost  all 
machines.  Several  large  high-quality  packages  have  been  implemented  in  Fortran  and  made 
available  on  a wide  range  of  computers.  Examples  are  the  Numerical  Algorithms  Group  (NAG) 
library  of  subroutines,  the  computer  graphics  package  GINO-F  and  the  engineering  design  system 
GENYSIS. 

Nevertheless,  numerous  defects  in  the  language  can  easily  trap  the  unwary.  Implicit  truncation  on 
assignment  to  an  integer  is  an  obvious  trap  that  is  compounded  by  the  lack  of  any  definition  in  the 
standard  of  the  semantics  of  the  truncation  |ANSI  66).  No  facilities  are  provided  for  fixed  point 
variables,  although  there  is  a significant  (but  small)  need  for  them,  especially  on  computers 
without  floating  point  hardware. 


5.1.1  Floating  Point:  The  Problems 


Surprisingly,  control  of  floating  point  precision  is  the  most  difficult  area,  and  no  completely  ade- 
quate solution  is  available.  Fortran  does  not  define  the  accuracy  of  single  precision,  which  in  con- 
sequence varies  on  common  systems  from  24  to  48  bits  in  the  mantissa.  Therefore  it  is  necessary 
to  choose  between  single  and  double  precision  according  to  the  implementation  being  used. 

Changing  precision  is  extremely  awkward:  declarations  can  easily  be  altered  although  implicit 
declarations  will  not  be  changed,  floating  point  literals  must  have  their  exponents  changed,  all 
intrinsic  functions  altered,  etc.  Some  functions  have  no  double  length  counterpart  (there  is  no 
DFLOAT,  for  instance)  and  hence  careful  checks  are  necessary.  The  Numerical  Algorithms  Group 
overcame  this  by  an  elaborate  text  processing  package  (which  can  handle  other  problems  as  wel- 
l)[HF  76).  Programming  conventions  can  be  used  so  that  the  change  is  possible  with  a simple  text 
edit,  but  no  simple  solution  is  available;  for  instance,  use  of  double  length  throughout  is  not  effec- 
tive because  of  its  excessive  cost,  nor  is  changing  the  type  by  IMPLICIT  because  it  is  not  standard 
Fortran  and  literals  cannot  be  changed  in  this  way. 
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Several  languages  in  the  Algol  60  tradition  (Pascal,  Coral  66,  RTL/2,  etc)  admit  only  one  floating 
point  data  type.  In  some  cases,  such  a simple  solution  can  meet  the  users  requirements  better  than 
can  Fortran,  The  two  Algol  60  compilers  for  the  IBM  360  allow  the  user  to  determine  (by  a com- 
piler directive)  whether  32  or  64  bit  precision  will  be  used  - a substantially  easier  task  than  the  cor- 
responding change  in  Fortran.  In  essence,  there  is  only  one  floating  point  concept  and  hence, 
unless  the  declarations  can  determine  the  precision,  it  is  best  to  have  only  one  data  type. 

Precision  control  in  Algol  68  is  by  declaration  of  long  real  or  even  long  long  real,  but  since  the 
accuracy  is  implementation  dependent,  declarative  changes  to  the  program  are  still  necessary. 
Nevertheless,  very  simple  textual  changes  to  an  Algol  68  program  could  map  floating  point 
declarations  into  an  efficient  program  giving  the  required  accuracy.  Any  language  with  user- 
defined  types  and  some  method  of  precision  control  provides  the  essential  mechanism  for  an 
effective  solution.  Careful  use  of  the  typing  facility  to  permit  simple  remapping  is,  of  course, 
imperative. 


5.1.2  Fixed  Point:  The  Problems 


There  is  also  considerable  difficulty  in  formulating  a satisfactory  fixed  point  facility.  The  Steelman 
requirements  specify  an  exact  representation  and  operations  for  exact  computation.  Part  of  this 
requirement  was  met  with  the  exceedingly  simple  facilities  in  the  preliminary  definition  of  the 
Green  language.  Extensions  merely  to  provide  multiplication  and  division  give  problems.  Applica- 
tions demand  arbitrary  scales,  not  just  powers  of  2 or  1 0,  in  which  case  the  scale  of  a product  may 
not  match  the  required  scale.  It  is  possible  to  use  the  greatest  common  divisor  algorithm  to  deter- 
mine the  scaling  required,  but  this  is  incompatible  with  a simple  semantics  that  is  so  important  for 
programmer  comprehension. 

Cobol  apparently  meets  the  Steelman  requirements,  but  only  by  using  decimal  scales.  Decimal 
scales  are  not  adequate  for  two  reasons:  first,  this  is  not  necessarily  the  scaling  required  by  the 
application,  and  second,  10  is  too  coarse  for  the  standard  16-bit  minicomputer.  A glance  at  a 
Cobol  manual  will  also  indicate  that  explaining  the  implicit  decimal  point  to  the  programmer  is  not 
as  easy  as  it  may  seem. 

One  possibility  is  to  allow  the  user  to  specify  a number  of  scales  connected  by  fixed  conversions, 
such  as  seconds  and  minutes.  Although  this  meets  some  application  needs  well,  it  is  insufficient  in 
other  cases.  The  extensions  required  seem  endless. 

It  is  important  to  note  that  the  package  module  facility  of  Green  allows  the  user  to  write  lus  own 
library  for  exact  computation  using  integers.  Compared  with  built-in  facilities  for  fixed  point,  the 
main  difference  is  the  lack  of  a good  notation  for  literals  and  some  loss  of  efficiency.  Since 
language  simplicity  is  such  an  important  goal,  fixed  point  should  only  be  included  if  the  need  is 
clearly  established  and  the  requirement  well  specified.  Neither  position  can  be  confirmed,  and 
hence  we  conclude  that  exact  fixed  point  facilities  should  not  be  included  in  the  language  design. 

An  analysis  of  actual  applications  in  many  real-time  situations  reveals  that  there  is  a need  for 
cheap  floating  point,  as  has  been  noted  in  many  reports  to  the  US  Department  of  Defense.  Small 
but  frequently  executed  computations  are  performed  upon  digital  input  signals.  The  very  simplest 
machines  may  not  have  floating  point  and  hence  some  means  is  required  to  perform  the  computa- 
tions quickly  (i.e.  software  or  firmware  emulation  of  floating  point  is  not  fast  enough).  To  say  thai 
in  the  future  floating  point  hardware  will  always  be  available  may  not  be  the  answer.  First,  floating 
point  data  require  more  space  and  second,  source  data  input  is  initially  fixed.  Hence  approximate 
fixed  point  is  a better  match  to  common  application  needs  than  floating  point. 
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As  we  shall  see,  it  must  be  admitted  that  programming  with  fixed  point  is  much  more  difficult  than 
with  floating  point.  On  the  other  hand,  fixed  point  is  potentially  more  reliable  because  tight  bounds 
must  be  placed  upon  data  values  in  order  to  perform  effective  error  analysis. 

Our  conclusion  is  that  approximate  fixed  point  is  the  most  likely  avenue  to  provide  an  arithmetic 
capability  complementary  to  integers  and  floating  point. 


5.1. 3 Overview  of  Numerics  in  Green 


The  facility  for  numerics  is  based  upon  the  idea  that  a numeric  variable  has  an  abstract  value  Such 
values  can  be  thought  of  as  subsets  of  the  real  numbers.  Exact  computation  is  only  provided  with 
the  integers.  Approximate  computation  is  provided  in  two  forms:  fixed  point  with  an  absolute 
bound  on  the  error,  and  floating  point  with  a relative  bound  on  the  error.  The  approximate  types  are 
called  real  types  since  they  can  be  thought  of  as  approximations  to  the  mathematical  concept  of  a 
real  number. 

The  semantics  of  each  numeric  operation  is  derived  from  the  type  of  its  operands.  Since  the 
language  provides  overloading  of  operators  the  operations  available  to  the  programmer  include 
not  only  those  derived  from  the  predefined  types,  but  also  those  introduced  by  the  programmer. 

The  facility  for  numerics  is  based  upon  three  unnamed  types,  called  universal  integer  univer- 
sal float,  and  universal  fixed.  These  types  are  abstractions  of  the  specific  types  in  a given 
implementation. 

(1)  Universal  Integer 

There  is  an  implementation  defined  type  INTEGER  which  is  equivalent  to  the  type  univer- 
sal integer  with 

range  INTEGER'FIRST  ..  INTEGER'LAST 

as  the  range  constraint.  This  constraint  reflects  the  maximum  integer  range  (often  one  word)  of  the 
machine.  Integer  constraints  are  of  type  universal  integer.  The  type  universal  integer  is  an  integer 
type  with  a range  constraint  large  enough  to  encompass  every  conceivable  integer  implementa- 
tion. Since  the  name  universal  integer  is  hidden  from  the  user,  he  cannot  declare  variables  or 
otherwise  make  use  of  this  type. 

Additionally,  an  implementation  may  provide  types  LONGJNTEGER  and  SHORTJNTEGER  with 
larger  and  smaller  ranges  than  INTEGER.  The  largeot  and  smallest  integer  values  that  are  sup 
ported  by  an  implementation  are  SYSTEM  MAX_INT  and  SYSTEM  MIN JNT  respectively 

(2)  Universal  Float 

There  is  a universal  type  for  floating  point  numbers.  The  precision  of  this  type  is  finite,  but  suf- 
ficiently long  to  encompass  any  implemented  floating  point  type.  Implementation  defined  types 
can  be  derived  from  universal  float  by  constraining  the  precision  to  the  machine  implemented 
precisions.  Such  types  have  defined  names,  for  example  FLOAT,  LONG_FLOAT.  etc.  The  user  may 
define  his  real  types  in  terms  of  the  machine  types,  or  simply  by  stating  the  required  precision 


(3)  Universal  Fixed 


There  is  also  a universal  type  for  fixed  point  numbers.  This  type  is  non-discrete  like  floating  point, 
but  the  magnitude  of  errors  with  this  type  is  absolute  lather  than  relative  (as  with  floating  point 
types).  This  absolute  magnitude  of  errors  is  called  the  delta.  The  representation  of  fixed  point  types 
depends  upon  the  largest  absolute  value  in  the  range  and  the  required  deltu.  For  instance,  a max- 
imum value  of  1024  wi.  \ a delta  of  1 will  require  10  bits,  leaving  6 guard  bits  on  a 1 6-bit  machine 
(ignoring  the  sign).  The  universal  fixed  type  has  a finer  delta  than  any  implemented  fixed  type.  The 
effective  use  of  fixed  point  depends  critically  upon  the  proper  specification  of  the  range  and  delta. 

The  universal  types  have  no  defined  operation,  since  the  representation  cannot  be  fixed  at  this 
level  of  abstraction.  Approximate  constants,  that  is  numeric  constants  with  a decimal  point  or  an 
exponent,  are  of  type  universal  float  or  universal  fixed,  depending  upon  the  context.  Hence  the 
machine  value  used  to  represent  the  constant  will  be  within  the  needed  accuracy 

Dividing  the  literals  into  integer  or  real  types  has  obvious  advantages  in  implementation  and 
description.  Within  an  expression,  the  type  of  a literal  need  not  be  specified  by  qualification  if  the 
context  determines  the  type.  However,  no  implicit  conversions  are  performed  between  integer 
numbers  and  approximate  numbers. 


5.2  The  Integer  Types 


The  operations  defined  for  the  integer  types  are 


Operator 

Meaning 

Result  7 ype 

+ - 

identity  and  negation 

operand  type 

+ - 

addition  and  subtraction 

operand  type 

* 

multiplication 

operand  type 

/ 

integer  division 

operand  type 

mod 

remaindet  on  integer  division 

operand  type 

* 4 

exponentiation 

operand  type 

relational  operators 

usual  semantics 

BOOLEAN 

New  integer  types  derived  by  imposing  constraints  on  INTEGER  inherit  these  operations.  The 
result  type  is  always  the  type  of  the  operands  (except  of  course  for  the  lelational  operators).  If  type 
LONG_INTEGER  is  also  implemented,  then  this  has  the  same  operations  as  above,  but  it  is  neces- 
sary to  overload  the  operations  to  obtain  the  required  semantics  This  step  corresponds  to  the  need 
for  the  implementation  to  generate  code  for  such  extended  integers 

The  type  SHORT_INTEGER  may  also  be  implemented  with  tea  above  semantics  Note,  however, 
that  this  type  can  readily  be  defined  by  the  user  with  a type  declaration  (assuming  1 6 bits)  like: 

type  SHORTJNTEGER  it  range  -32768  32767; 

The  numeric  values  after  range  are  used  to  determine  the  appropriate  implemented  type.  For  a 
program  requiring  large  integers  we  could  define 

type  MY.. INTEGER  it  range  100.000  . 100.000; 
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This  type  would  be  implemented  with  the  machine  type  LONGJNTEGER  on  a typical  16-bit 
minicomputer,  but  with  ordinary  integers  (i.e.  INTEGER)  on  a larger  word  length  machine.  If  the 
range  cannot  be  determined  at  compilation  time,  then  type  INTEGER  is  used. 

The  operations  / and  mod  require  explanation.  There  is  no  universal  agreement  on  the  semantics  of 
these  operations  for  negative  operand  values.  Of  course,  negative  values  are  not  commonly  used 
Because  different  machines  perform  the  corresponding  operation  differently,  it  is  tempting  not  to 
define  the  operation  for  negative  values.  This  is  the  approach  taken  in  the  axiomatic  definition  of 
Pascal.  The  semantics  chosen  in  the  Green  language  corresponds  to  division  by  truncation  toward 
zero  (so  (-3)/2  = -1).  This  has  the  advantage  that  the  usual  identity 

-IA/B)  = (-AI/B  = A/l-B) 

also  applies  to  integer  division. 

The  operations  / and  mod  are  related  by 

A = (A/B)*B  4-  (A  mod  B) 

and  the  sign  of  the  result  of  the  mod  operation  is  the  same  as  the  sign  of  A.  (Hence  A mod  1 0 can 
be  negative).  Also  the  absolute  value  of  the  result  of  the  mod  operation  is  less  than  the  absolute 
value  of  B (which  implies  that  the  operation  is  not  defined  for  B = 0). 

The  exponentiation  operator  is  only  permitted  with  a positive  exponent.  Hence.  X**(-1)  will  fail  at 
compilation  time  as  the  exponent  is  not  positive.  The  operation  is  defined  as  repeated  multiplica- 
tion of  the  left  hand  operand.  The  number  of  multiplications  is  one  less  than  the  exponent  value 
(i.e.  X**2  = X*X). 

Subtypes  of  integer  types  can  be  defined  by  use  of  range  constraints.  Variables  of  a subtype  have 
the  operations  of  the  type  but  each  assignment  must  conform  to  the  range  constraint.  One  would 
expect  compilers  to  represent  subtypes  in  the  same  way  as  types,  but  in  special  cases,  the  com- 
piler may  be  able  to  optimize  the  representation  by  utilizing  the  range  constraint. 

The  absolute  value  operation  is  accomplished  with  the  predefined  function  ABS,  which  is  defined 
for  all  numeric  types. 


5.3  The  Real  Types 


The  real  types  form  two  classes:  floating  point  types  and  fixed  point  types.  Both  are  approximate 
and  are  different  forms  of  approximation  to  the  real  numbers  of  mathematics.  With  floating  point 
types,  the  error  in  representing  a mathematical  value  is  roughly  proportional  to  its  absolute  value 
over  a large  range.  In  contrast,  the  error  with  a fixed  point  value  has  an  absolute  bound,  so  that 
small  values  have  a correspondingly  large  relative  error. 

The  accuracy  constraint  specifies  bounds  on  the  permitted  error  in  the  representation  of  values: 
the  precision  for  floating  point  and  the  delta  for  fixed  point.  The  accuracy  constraint  is  handled  by 
the  compiler  and  in  consequence  there  is  no  exception  corresponding  to  the  RANGE_ERROR  for  a 
range  constraint.  Delta  is  an  absolute  numeric  value  and  hence  should  be  specified  as  a fixed  point 
value.  Precision  is  relative  and  for  consistency  should  be  a floating  numeric  value  but  there  is  no 
doubt  that  specification  by  the  number  of  significant  decimal  digits  is  more  natural.  Note  that 
specification  of  delta  in  terms  of  decimal  digits  is  too  coarse  for  a binary  machine,  and  in  any  case 
would  be  unnatural  as  delta  is  an  absolute  value. 
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The  predefined  operations  provided  tor  tloating  and  fixed  types  differ  in  detail  in  order  to  reflect 
correctly  the  handling  of  error  bounds  within  a computation.  The  accuracy  constraints  determine 
parameters  to  a semantic  model  for  the  real  types  which  is  used  to  bound  errors  on  the  predefined 
operations. 

There  are  five  predefined  attributes  which  apply  to  both  classes  of  real  types.  R'FIRST  and  R'LAST 
are  values  of  type  R which  bound  all  the  values  of  R.  The  integer  value  R'BITS  gives  the  number  of 
binary  places  for  the  mantissa  (floating  point)  or  magnitude  (fixed  point)  in  the  abstract  representa- 
tion (see  5.3.3  also).  R'SMALL  and  R'LARGE  are  values  of  the  universal  float  or  universal  fixed 
type  which  are  respectively  the  smallest  positive  non-zero  value  and  the  largest  positive  value  in 
the  abstract  representation. 


5.3.1  Floating  Point  Types 


Operations  on  the  floating  types  are  defined  at  the  level  of  FLOAT  and  LONG_FLOAT  etc.  These 
operations  are 


Operator 

+ - 
+ - 
* 

/ 

* ♦ 

relational  operators 


Meaning 

addition  and  subtraction 

identity  and  negation 

multiplication 

division 

exponentiation 

tright  operand  any 

integer  type) 

usual  semantics 


Result  Type 

operand  type 
operand  type 
operand  type 
operand  type 
type  of  left  operand 


BOOLEAN 


The  operators  = and  /=  could  have  been  excluded  because  their  semantics  is  of  doubtful  validity, 
since  the  representation  is  approximate.  Given  a precision  of  6 digits,  then  equality  could  either 
mean  equality  of  representation  (which  would  typically  be  of  higher  precision)  or  equality  only  to  6 
digits. 


The  decision  has  been  to  allow  equality  since  it  is  defined  for  all  other  types.  The  user  must  be 
aware  that  the  implemented  precision  is  used  and  that  in  . „nsequence  code  may  be  non-portable. 
(The  situation  is  no  better  with  languages  other  than  Green).  The  semantic  model  of  Brown  (see 
below)  handles  this. 


The  types  FLOAT  and  LONG_FLOAT  have  an  implementation  defined  precision.  Derived  types  can 
be  defined  by  constraining  the  range  and  reducing  the  precision  requirement.  The  compiler  must 
check  (as  with  other  constraints)  that  these  constraints  are  legitimate.  Hence,  in  practice,  at  the 
machim  level  there  will  be  only  one  or  two  implemented  precisions.  The  type  declarations  may 
specify  the  required  precision  and  the  predefined  machine  type  name  (or  other  defined  floating 
type). 

A user  may  also  define  floating  point  types  directly  in  terms  of  their  precision  and  range,  and  this  is 
preferable  for  portability.  In  this  case  the  types  are  mapped  on  the  nearest  applicable  machine 
implemented  precision.  As  an  example  consider  the  type  declarations 
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type  MY_SHORT_  FLOAT  to  digits  6 ran**  MIN  MAX 

type  MY  FLOAT  to  digits  B rang*  MIN  MAX 

type  MY  .LONG-FLOAT  to  digits  10  ranpa  MIN  MAX 

On  a machine  Ml  tor  which  the  implemented  precision  provides  7 digits  tor  FLOAT  and  14  tor 
L0NG_FL0AT  these  declarations  have  the  same  effect  as 

type  MY-SHORT.FLOAT  to  new  FLOAT  digits  6 ranpa  MIN  MAX 

typa  MY.FLOAT  to  new  LONG-FLOAT  digits  8 ranpa  MIN  MAX 

typa  MY-LONG-FLOAT  to  new  LONG-FLOAT  dipits  10  ranpa  MIN  MAX 

On  a machine  M2  *or  which  the  implemented  precisions  provide  8 digits  tor  FLOAT  and  16  for 
long_float.  these  declarations  have  the  same  effect  as 

type  MY-SHORT-FLOAT  to  new  FLOAT  dipits  6 ranpa  MIN  MAX 

type  MY.FLOAT  is  new  FLOAT  dipits  8 ranpa  MIN  MAX 

type  MY-LONG-FLOAT  to  new  LONG.  FLOAT  digits  10  ranpa  MIN  MAX 

If  the  range  constraint  is  omitted  in  the  type  declaration,  then  the  range  is  inherited  from  the 
implemented  type.  The  mathematical  library  is  of  course  defined  in  terms  of  the  types  FLOAT 
LONG-FLOAT,  etc.,  and  is  hence  inherited  by  the  user  defined  types  If  the  user  writes  SQRT|X) 
where  X is  of  type  MY_FLOAT.  then  on  machine  Ml  the  SORT  function  defined  for  LONG  FI  OAT 
will  be  used  whereas  on  machine  M2  it  will  be  the  SORT  function  defined  for  FLOAT  Of  course 
thj  user  may  always  write  a special  SORT  function  say  for  type  MY  REAL  which  may  compute  a 
resuu  with  exactly  8 digits  of  precision  rather  than  14  on  machine  Ml  and  8 on  machine  M2 


To  summariie,  the  language  provides  a direct  and  simple  mechanism  tor  achieving  efficient  use  of 
the  available  precisions  predefined  by  a given  implementation 

The  exponentiation  operation  for  floating  point  operands  is  defined  by  repeated  multiplication  in 
the  same  way  as  with  integers.  For  a negative  exponent  the  value  is  the  reciprocal  of  the  value 
with  the  positive  exponent  The  exponent  can  be  of  any  integer  type 

The  predefined  attribute  R DIGITS  is  the  value  (of  type  INTEGER'  which  appears  as  the  accuracy 
constraint  giving  the  precision  of  the  type  or  subtype  R 

Example 

Consider  the  following  function  a typical  library  routine  using  FLOAT  and  LONG  FLOAT  directly. 

function  DOT..PRODUCT  (X.Y:  FLOAT-VECTOR)  return  FLOAT  1s 
SUM:  L0NG_FL0AT; 

begin 

aeeert  (X  FIRST  - Y FIRST), 
assert  IX  LAST  - Y LAST); 
for  I In  XFIRST  ..  X LAST  loop 

SUM  :»  SUM  * LONG  .FLOATlXd))*  LONG  FLOATIY(D): 

end  loop. 

return  FLOAT(SUM): 
end  DOT-PRODUCT; 

If  the  machine  has  an  instruction  which  forms  the  double  length  product  from  two  single  length 
operands,  it  is  fairly  simple  for  a peephole  optimizer  to  use  this  instruction  in  the  innei  loop  (rather 
than  expand  each  operand  and  multiply). 
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It  an  application  requires  floating  point  computation  with  multiple  precisions  then  two  means  can 
foe  used  to  achieve  this  the  use  ot  subtypes,  and  the  use  of  types 


Use  of  Subtypes 


To  use  subtypes  a type  must  foe  declared  with  the  largest  required  precision,  for  example 

type  MY  .REAL  it  digits  20. 

Then  variables  or  subtypes  can  be  declared: 

X MY_REAL:  - digits  20 

Y MY  REAL  digits  15: 

subtype  SHORT  REAL  is  MY.REAL  digits  10; 

Z1  Z2.  Z3  SHORT_REAL 

The  operations  on  MY  REAL  are  defined  for  all  variables  of  the  type  (X,  Y Z1 . Z2,  Z3).  Hence  it  is 
not  possible  to  provide  an  overloaded  SORT  function  just  for  SHORT, REAL.  Similarly,  the  error 
analysis  is  dependent  on  the  operators  for  the  type  MY_REAL. 

An  optimizing  compiler  may  be  able  to  use  single  length  data  representation  for  each  variable,  but 
this  depends  upon  the  variables  being  invisible  to  other  compilation  units  and  on  the  ability  of  the 
compiler  to  establish  that  the  semantics  will  be  preserved  If  an  implementation  uses  call  by 
reference  for  in  out  parameters,  then  arrays  of  SHORT_REAL  will  have  to  be  handled  in  the 
representation  of  MY_REAL  (to  avoid  the  alternative  of  excessive  copying). 

Note  that  thu  declaration  of  Y is  also  an  implicit  assertion  that  the  precision  of  MY_REAL  is  at  least 
1 5 digits.  This  could  be  useful  for  defensive  programming  in  large  systems.  For  example,  if  in  a 
later  revision  of  the  program  the  precision  of  the  type  MY_REAl  is  reduced  by  more  than  5.  then 
an  error  message  will  be  reported  upon  recompilation  of  the  declaration  of  Y 


Use  of  Types 


To  use  types  each  distinct  class  of  numbers  would  have  a different  type,  with  a precision 
appropriate  to  the  task  being  performed  Security  is  better  than  with  the  use  ot  subtypes  but  all 
conversions  must  be  explicit  On  the  other  hand,  inserting  the  conversion  to  another  target  com 
puter  is  simple  and  efficient.  This  is  because  each  type  is  mapped  separately  using  only  as  much 
precision  as  necessary  Of  course,  the  efficiency  is  also  high  for  the  initial  application  computer  as 
well,  since  even  a non  optimizing  compiler  will  map  each  type  onto  the  appropriate  hardware  type 

Both  cases  above  assume  that  the  programs  have  been  written  well  using  named  types  or  s b 
types.  Direct  use  of  FLOAT  and  LONG  FLOAT  is  absent  so  that  no  assumption  has  been  made  on 
the  precisions  of  these  types. 


5.3.2  Find  Point  Typos 


The  definition  of  the  fixed  point  types  is  more  difficult  for  several  reasons  hrst.  the  ^presentation 
cannot  be  determined  until  both  the  range  and  delta  are  known  These  two  parameters  determine 
the  width  required  in  bits  and  the  position  of  the  decimal  point  A user  could  give  a representation 
specification  giving  only  the  number  of  bits  needed  Having  determined  these,  the  representation 
is  fixed  and  the  operations  can  be  defined  The  second  problem  is  that  the  type  resulting  from  mul 
tip'.ication  and  division  is  universal  fixed.  Since  no  operations  are  available  on  universal  types  an 
expression  must  be  qualified  with  the  required  type  (or  subtype) 

In  a fixed  point  type  declaration,  the  value  following  delta  and  the  two  range  values  (which  must 
be  provided)  are  of  any  fixed  point  type  but  must  have  a value  determined  at  compilation  time  In  a 
subtype  declaration,  the  delta  value  must  be  larger  than  that  of  the  type  and  the  range  constraint 
values  must  be  within  the  values  of  the  type 

Consider  the  type 

type  F is  delta  0.01  range  >100  0 . 100  0. 

We  assume  the  target  machine  to  be  a 16-bit  minicomputer  using  two  s compleme  nt  anthmetic. 
The  implemented  range  would  be  the  next  power  of  two  1-128  127)  or  7 bits  above  the  decimal 

point.  Similarly  7 bits  are  required  below  the  decimal  point.  Hence  15  bits  are  required  (sign  7 
above  decimal  point.  7 below  decimal  point),  leaving  one  spare  bit  at  the  bottom  of  the  word  to 
provide  a (fortuitous)  guard  bit. 

Given  two  fixed  point  types  F and  G then  we  have  the  following  operations: 


Operator 

Meaning 

Operand  Types 
Left 

Right 

Result  Type 

f - 

identity  and 
negation 

F 

F 

♦ - 

addition  and 
subtraction 

F 

F 

F 

integer 

multiplication 

F 

any  integer 
type 

F 

* 

integer 

multiplication 

any  integer 
type 

F 

F 

* 

fixed 

multiplication 

F 

G 

universal  fixed 

/ 

fixed 

division 

F 

G 

universal  fixed 

/ 

fixed  division 
by  integer 

F 

any  integer 
type 

F 

relational 

operators 

usual 

semantics 

F 

F 

BOOLEAN 
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The  semantics  of  these  operations  in  terms  of  the  permitted  rounding  error  requires  care  The  basic 
source  of  error  is  the  representation  of  constants  and  intermediate  results  If  EPSUON  is  half  the 
delta  of  F (that  is  EPSILON  F DELTA/2)  then  a constant  C is  represented  by  a machine  value  Cl 
such  that 

C - EPSILON  < Cl  < C ♦ EPSILON 
The  operations  above  that  yield  a result  type  universal  fixed  obey  a similar  inequality: 

X Y F 

X.Y  - EPSILON  < FIX* Y)  v X.Y  + EPSILON 
X/Y  - EPSILON  <-  F(XV)  < X/Y  ♦ EPSILON 

where  the  upper  and  lower  limits  are  calculated  mathematically  A value  C is  representable 
without  error  if  Cl  C.  Computations  with  such  values  are  exact,  except  for  division  and  fixed 
point  multiplication  This  can  easily  be  seen  by  thinking  in  terms  of  a decimal  calculator  no  extra 
digits  are  needed  Note  that  integer  multiplication  is  essentially  repeated  addition  it  can  overflow 
but  cannot  lose  accuracy.  Note  also  that  integer  multiplication  by  a floating  point  value  is  not  per 
mitted  since  this  is  not  equivalent  to  repeated  addition.  Hence  the  integer  operand  must  be 
explicitly  floated  The  user  could  define  this  operation  if  required. 

The  operations  of  fixed  multiplication  and  division  are  essentially  in  two  parts  First,  the  accurate 
product  is  formed  (that  is.  a result  of  the  type  universal  fixed  is  obtained)  Second  the  result  must 
be  qualified  before  being  assigned  to  any  variable  or  being  used  in  further  computation.  This 
qualification  may  imply  a loss  of  accuracy  due  to  the  representation  in  the  destination  type.  The 
operation  of  fixed  division  by  an  integer  operates  in  an  analogous  way  and  is  merely  provided  to 
avoid  excessive  explicit  type  conversions 

The  predefined  attribute  R DELTA  for  a fixed  point  type  is  a value  of  type  universal  fixed  which  is 
that  given  in  the  accuracy  constraint  of  the  type  or  subtype  R 

To  understand  the  computational  aspt  cts  it  is  simplest  to  consider  a decimal  machine  Take  a 
word  as  being  a sign  and  three  digits  ISDDD)  and  consider  the  following  declaration 

type  FRAC  is  delta  0 001  range  0 999  0 999 

This  type  requires  all  of  the  word  with  the  representation  S DDD  (i.e  the  point  next  to  the  far  left  of 
the  word). 

Consider  also 

type  LARGE  is  delta  10  0 range  800  0 800  0 

This  would  ordinarily  be  implemented  as  (SDDD  ),  with  one  uard  digit.  Note  that  in  many  cases 
bit  patterns  do  not  give  valid  values  (as  with  subranges  of  integers) 

Finally,  consider 

type  MEDIUM  ia  delta  0.2  range  9 0 9.0 

This  would  have  the  representation  tSD.DD)  with  more  than  one  guard  digit 


i 


til 
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We  can  illustrate  the  use  of  these  types  as  follows 


FI.  F2:  FRAC; 

LI.  L2:  LARGE: 

Ml.  M2:  MEDIUM: 

Ft  :=  03333; 

FI  :=  FI  + 0.1: 

FI  :=  2.F1: 


— last  digit  3 lost  on  conversion  to  FRAC 

- Now  |F1  - 0 33331  <=  FI  DELTA 

— 0.1  needs  no  qualification  as  the  left  operand 
--  specifies  the  type  (FRAC)  of  0 1 

- Now  FI  = 0 866 


FI  :=  FI/2: 


— equivalent  to  FI  :=  FRAC(F1/2.0>,  i.e. 

— integer  division  avoids  qualification 


FI  :=  FRAC(2.3*F1 ); 


LI  :=  700.0: 


--  the  constant  is  represented  with  as  much  significance 

— as  the  other  operand.  The  machine  evaluates 

— 2 30*0  433  = 0 99590  (six  digit  answer)  and  then 
--  rounds  the  result  to  0 996,  which  is  stored  in  FI. 

— Note  that  rounding  is  needed  (no  guard  bit). 

— the  0 is  necessary.  This  emphasizes  approximation 


LI  :=  LARGEIF1  *L1 1; 


— calculates  700.0*0  996  = 697.20.  rounds  to  697.0 


LI  :=  LARGE(F1*L1)  + LI;  --  qualification  is  necessary,  and  serves 

— to  emphasize  rounding  before  addition 

L2  :=  LARGE(F1*L1)  + 100.0;  --  qualification  is  necessary 

if  LI  > FI  than  — not  permitted,  must  be  of  same  type 

if  LI  > LARGE(L2*F1)  than  — permitted,  explicit  conversion 

Fixed  point  operators  = and  /=  are  permitted  for  the  same  reason  as  for  floating  point. 

The  user  can  perform  accurate  computation  with  fixed  point  by  ensuring  that  only  exactly 
representable  values  are  used.  In  fact,  the  only  source  of  error  is  the  implied  rounding  of  constants 
and  conversion  (which  are  necessary  for  multiplication  and  division).  Note  that  a major  source  of 
error  in  the  above  may  be  the  representational  error  of  the  values  rather  than  in  calculating  their 
product. 

Example : 

A frequent  calculation  in  some  numerical  applications  is  the  smoothing  of  an  input  sequence  by 
means  of  a running  average: 

OLD.VAL  :=  0.9*OLD_VAL  + 0.1*NEW_VAL; 
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To  program  this  in  Green  the  right  hand  side  must  have  the  type  specified  for  at  least  one  of  the 
products  An  error  analysis  reveals  that  a small  error  in  the  constant  0.9  will  cause  a much  larger 
error  in  0LD_VAL  after  successive  iterations  (a  constant  value  of  10  0 as  input  converges  to  9.09 
if  0 9 is  replaced  by  0 89).  To  avoid  this  cumulative  effect,  one  can  write  the  following 

OLD_VAL.  NEW_VAL:  F; 

OLD_VAL  :=  0LD_VAL  ♦ F(0  1 * (NEW_VAL  0LD_VAL)>: 

Example. 

Consider  the  following  function  for  computing  the  average  of  an  array  of  components  as  follows. 

function  AVERAGE  (A  FIXEOJ/ECTORI  return  F is 
NUMJTEMS  : constant  INTEGER  .=  ALENGTH; 

typo  SUMF  is  dstta  F’ DELTA  rang*  NUMJTEMS.F' FIRST  . NUMJTEMS. FLAST; 

SUM:  SUMF  :=  0 0; 

b*gin 

for  I in  A FIRST  ..  A LAST  loop 
SUM  ;=  SUM  > SUMFIA(I)); 

and  loop: 

return  FISUM/NUM  JTEMS) 

and: 

Here,  the  type  SUMF  has  a greater  range  than  F to  accommodate  the  larger  potential  range  of 
values.  The  explicit  conversion  inside  the  loop  does  not  lose  accuracy,  but  the  final  division  will 
lose  potential  accuracy.  If  type  F requires  nearly  a full  word,  then  the  type  SUMF  will  be  double 
length.  It  is  very  difficult  to  write  an  algorithm  to  obtain  the  average  which  avoids  double  length. 
Since  the  size  of  the  array  is  involved  in  the  type  SUMF.  this  size  must  be  known  at  compilation 
time. 


5.3.3  A Semantic  Model  for  Approximate  Computation 


Programming  languages  do  not  conventionally  define  the  semantics  of  floating  point  arithmetic. 
However,  in  this  language,  with  declarations  controlling  the  accuracy  of  data  types,  it  is  highly 
desirable  to  do  so.  Recent  work  by  W.  S.  Brown  [Br  78]  makes  it  possible  to  describe  a model 
which  is  both  clean  in  structure  and  realistic  (i.e.  it  describes  the  actual  behavior  of  floating  point 
units).  In  this  section,  a brief  overview  is  given  of  the  model  as  needed  by  the  language. 

For  each  type,  an  abstract  representation  is  defined.  Take  the  declaration: 

type  F is  digits  6; 
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This  corresponds  to  20  binary  digits  (i.e.  F'BITS  = 20),  and  so  the  abstract  representation  is  of  the 
form  of  zero  or  of  the  form  of  a sign,  twenty  binary  digits,  and  an  integer  exponent.  For  non-zero 
values,  the  most  significant  binary  digit  is  1 . Such  values  can  be  given  in  a slightly  extended  form 
of  based  numbers,  for  instance: 

2 = 2#.1e2 

100  = 2#.11001e7 

0.25  = 2#.1e-1 

If  the  smallest  value  of  the  exponent  is  -99  then 
FSMALL  = 2*.1e-99 

If  the  largest  value  of  the  exponent  is  99,  then 
FLARGE  = 2#.1 1 1 1 1_1 1111 1 1ll  1_1 1 1 1 1e99. 

We  do  not  assume  that  numbers  are  represented  in  this  fashion,  merely  that  numbers  having  the 
numeric  values  given  above  are  representable  in  the  machine.  Brown  now  develops  axioms  for  the 
representable  numbers  and  the  behavior  of  a machine  number  bounded  by  an  interval  whose 
points  are  representable  numbers.  These  axioms  allow  the  use  of  higher  precision  than  specified  in 
the  declaration,  which  is  essential  in  Green,  since  the  implemented  precision  will  typically  be  larger 
than  the  declared  precision. 

For  fixed  point  types,  a similar  representation  is  chosen  without  an  exponent.  Axioms  (not  treated 
by  Brown)  can  now  be  given  which  reflect  the  exact  nature  of  some  operations  and  the  approx- 
imate nature  of  others.  In  addition,  because  of  the  obvious  correspondence  between  the  abstract 
representations  of  all  approximate  types,  conversions  can  be  defined. 

These  conversions,  and  some  use  of  subtypes  can  result  in  weaker  error  bounds  than  those  of  the 
type.  Consider: 

type  F is  digits  6; 

X : F; 

Y : F digits  5; 

The  statement  Y :=  X;  allows  an  implementation  to  "lose"  the  three  least  significant  binary  digits 
on  the  assignment.  Hence  X :=  Y;  will  then  mean  that  the  last  three  bits  of  X are  undefined  (i.e.  the 
interval  which  bounds  the  value  of  X is  larger  than  that  given  by  the  type). 

Example : 

Consider  an  example  with  a fixed  point  type  since  these  were  not  handled  by  Brown.  Take 
type  F is  delta  0.01  range  -100.0  ..  100.0; 

Then,  as  stated  above,  the  representation  uses  the  powers  of  2:  64,  32 1/128  to  cover  the 

required  dynamic  range. 

To  discuss  the  semantics,  we  again  write  model  numbers  in  an  obvious  extension  of  based 
numbers: 

64  = 2#  1000000.0000000 
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Then 


F FIRST  -2#  1 100100  0000000  100  0 

FLAST  2*  1 100100  0000000  = 100  0 

F'BITS  = 14 

F'SMALl  1/128  2*0000000  0000001  0078125k  01) 

F'LARGE  255  + 127/128  2^11  1111111111  11  255.9921875 

— F'DELTA  is  not  a model  number 

— F’FIRST  and  F LAST  are  model  numbers  in  this 

— example  but  this  need  not  always  be  the  case. 


Now  consider  the  representation  of  2.1,  as  in  the  declaration 
FI:  F :=  2.1; 

The  value  is  bounded  by  the  two  model  numbers 

2 + 12/128  ■=  2*0000010.0001100  = 2 09375 
2 + 13/128  = 2*0000010  0001101  = 2 1015625 

and  hence  these  two  values  give  bounds  for  FI . On  a 20-bit  machine,  FI  is  likely  to  be  represented 
by  the  machine  value  (using  the  same  notation)  of 

2 10009765625  8602/4096  2*0000010  000110011010 

The  error  analysis  of  ordinary  computation  proceeds  similarly.  Take: 

FI  :=  FI  + 2 0. 

Here  2.0  is  a model  number  (and  hence  is  represented  exactly).  So  as  a result,  the  bounds  for  FI 
are  now  4.09375  4.1015625.  If  the  operands  are  not  model  numbers,  then  the  corresponding 

bounds  are  used. 

The  logic  with  fixed  point  multiplication  and  division  is  slightly  different.  Take 
FI  :=  F(2.1  * FI); 

Here  2.1  is  of  universal  fixed  type,  and  the  context  requires  that  it  be  represented  to  the  same 
number  of  bits  as  FI . 

Hence  2.1  is  represented  as  2*10.0001 1001 1010  or  possibly  with  further  bits.  But  FI  is  less 
accurately  represented  because  of  the  zero  bits  at  the  top  of  the  word.  The  multiplication  provides 
an  accurate  product  bounded  (because  of  FI)  by  2.1*4  09375  ..  2.1  *4  101  5625.  The  qualifica- 
tion means  that  the  accuracy  of  the  result  is  bounded  by  F'DELTA  (or  better,  F’SMALL).  In  this 
case,  the  bound  derived  from  FI  is  large  and  in  consequence  the  new  bound  on  FI  is  about 
2.1+FDELTA.  On  the  other  hand,  if  both  of  the  operands  had  very  tight  bounds  (or  if  2.1  were 
replaced  by  anything  less  than  1 in  magnitude)  so  that  the  product  was  bounded  by  a value  less 
than  F DELTA,  then  the  bound  on  FI  after  the  assignment  would  be  F'DELTA. 


I 
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5.4  Implementation  Consideration* 


Fixed  point  types  can  be  represented  on  most  machines  with  one  or  two  machine  words 
Implementations  should  not  support  fixed  point  types  in  excess  of  this  length  if  credible  perfor 
mance  is  required  (and  cannot  be  provided)  Such  an  implementation  would  be  us  efficient  in  time 
and  space  as  conventional  assembler  coding  (assuming  a good  register  allocation  algorithm).  As 
with  subranges  of  integers,  tight  packing  is  possible  and  could  result  in  a major  advantage  over 
floating  point. 

Good  performance  depends  largely  upon  the  proper  specification  of  the  range  and  delta  For 
machines  with  limited  arithmetic  shifts  a range  which  excludes  negative  values  would  allow  the 
use  of  logical  shifts  for  scale  conversion.  All  type  conversions  with  fixed  types  could  be 
accomplished  with  simple  arithmetic  shifts  and  masking.  All  the  operations  are  likewise  straight 
forward 

With  real  types  there  is  a problem  about  the  end  points  of  the  range  with  a range  constraint. 
Ordinarily,  such  values  would  be  in  the  values  permitted.  However,  a fixed  point  range  0.0  . 1 .0  on 
a two  s complement  machine  would  not  usually  want  to  include  1 0 To  avoid  giving  ranges  as  0 0 
. 0.999999999,  it  seems  best  not  to  require  that  non-zero  end  values  are  within  the  specified 
range. 

A lazy  implementation  of  numeric  types  that  could  be  used  by  a diagnostic  compiler  is  as  follows 
Every  value  is  stored  in  long  floating  point  format  together  with  a flag  indicating  if  it  is  integer  or 
real.  The  long  format  must  be  sufficiently  long  to  encompass  the  longest  integer,  fixed  point  and 
floating  point  types  supported  by  the  implementation.  Operations  can  now  be  applied  to  these 
values,  the  flag  being  used  to  ensure  that  integer  results  are  correctly  rounded  to  integers  (if  the 
floating  point  hardware  does  not  give  integer  results  from  integer  values).  This  implementation 
method  is  clearly  inefficient,  especially  for  fixed  types  which  are  often  used  as  a method  of 
avoiding  expensive  floating  point.  However,  it  illustrates  the  concept  of  the  abstract  value  and  that 
the  operators  have  the  same  meaning  for  each  type. 

Although  it  is  theoretically  feasible,  it  is  not  practical  to  implement  floating  point  types  as  fixed 
foint  quantities.  This  is  because  of  the  potentially  large  dynamic  range  of  floating  point  values 
particularly  near  zero.  However,  a floating  point  type  whose  values  were  constrained  between  1 .0 
and  2.0  could  use  fixed  point.  Such  types  seem  unlikely  in  practice  since  even  negation  is  not 
defined 

With  the  real  types,  the  language  does  not  specify  rounding  or  truncation,  since  either  choice  will 
be  excessively  expensive  on  some  machines  However,  the  user  can  control  its  effect  by  increasing 
the  digits  or  the  delta  in  the  type  declaration.  Note  that  a small  decrease  in  the  delta  could  require 
going  from  1 word  to  2 words,  with  consequential  performance  degradation.  With  multiplication 
and  division,  rounding  may  be  required  to  preserve  the  relational  inequalities.  Exact  conversion  can 
only  occur  between  integer  types  (although  many  other  conversions  may  not  require  any 
rounding).  Note  that  conversions  are  effectively  via  universal  types  so  that  the  specification  only 
involves  one  type  (not  all  pairs).  No  conversions  are  significantly  more  troublesome  than  are 
integer  to  real,  real  to  integer  in  (say)  Algol  60 

Consider  a function  F_SQRT  for  taking  the  square  root  of  an  argument  ..here  the  argument  and 
the  result  are  of  type 

type  FRACTION  it  delta  D range  0.0  10 
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Given  the  fixed  point  quantities 

X V delta  I60*D  range  0 0 16  0; 

then  one  can  take  the  square  root  by 

Y .=  4.0  . FSORT(FRACTION(X/l  6.0)1; 

However,  the  division  by  16  is  a shift  that  corresponds  to  the  converse  of  the  FRACTION  type  con 
version  and  hence  produces  no  code  (assuming  reasonable  peephole  optimization).  Of  course,  the 
programmer  must  be  aware  that  this  is  the  case  on  a binary  machine. 

The  body  of  F_SURT  (tor  argument  range  0.5  to  1)  could  be: 

function  F_SORT(X:  FRACTION)  return  FRACTION  is 
APPROX  FRACTION; 

begin 

APPROX  0.5; 

while  ABSIAPPROX  FRACTION|APPROX/X))  > FRACTION' DELTA  loop 
APPROX  . FRACTIONIO.5  * (APPROX  + IFRACTION(APPROX/X))>; 
end  loop; 
return  APPROX; 
end  F_SORT; 

The  machine  dependence  is  largely  restricted  to  the  declaration  of  FRACTION,  whose  range 
relative  to  the  accuracy  would  reflect  the  word  length  of  the  machine.  Note  that  it  the  declared 
range  is  0.0  ..  1.0,  then  the  algorithm  may  give  values  equal  to  1.0  tor  arguments  near  1.0.  This 
would  cause  overflow  on  a two's  complement  machine.  The  check  for  negative  arguments  is 
implicit  in  the  type  definition. 

In  evaluating  an  expression  at  compilation  time,  the  identification  of  the  operators  must  be  per- 
formed Then  expressions  involving  only  literals,  other  evaluated  expressions  and  predefined 
operators  can  be  evaluated.  The  accuracy  of  real  arithmetic  may  be  different  from  that  of  the  target 
machine,  although  both  are  within  that  specified  in  the  type  declarations. 


5.5  Conclusions 


The  aim  of  the  proposals  is  to  provide  the  full  range  of  numeric  facilities  within  a secure  system  of 
types.  This  has  been  achieved  by  a combination  of  two  techniques.  Firstly,  use  is  made  of  the 
ability  in  the  language  to  define  new  types  derived  from  an  existing  type  from  which  the  new  types 
inherit  properties.  Secondly,  the  definition  of  the  accuracy  constraints  allows  a derived  type  to 
inherit  properties  from  an  existing  type  of  greater  accuracy. 

The  method  of  inheritance  from  a named  type  has  been  generalized  in  Green  so  that  the  underlying 
implemented  type  such  as  FLOAT  or  LONG_FLOAT  need  not  be  explicitly  named.  By  this  means, 
portable  and  efficient  implementation  is  ensured.  Although  several  types  might  be  derived  from 
FLOAT  isay),  they  are  distinct,  and  as  such  increase  security  since  no  implicit  conversion  is  permit- 
ted. The  formulation  of  the  accuracy  constraints  is  vital,  since  the  constraint  determines  the 
characteristics  of  both  classes  of  real  types. 
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Due  to  recent  research,  it  is  possible  to  define  an  axiomatic  system  which  gives  the  minimal 
properties  of  approximate  computation.  These  minimal  accuracy  properties  could  be  exploited  by  a 
diagnostic  or  program  analysis  system  to  ensure  that  the  algorithm  being  used  is  appropriate.  The 
axiomatic  system  is  realistic  in  the  sense  that  it  can  (and  must)  be  applied  to  existing  floating  point 
implementations. 

The  numeric  types  available  to  the  programmer  are  derived  from  those  defined  in  the  implements 
tior..  This  guarantees  that  the  effiency  of  the  resulting  code  is  directly  related  to  that  of  the 
implementation,  which,  in  the  case  of  floating  point,  could  be  hardware  firmware  or  software.  Fix 
ed  point  types  are  not  predefined  in  the  standard  environment,  but  acquire  their  properties  on 
declaration.  However,  in  terms  of  code  generation  these  properties  involve  little  more  than  that  of 
the  integers  and  hence  the  performance  should  be  high. 

Portability  cannot  be  guaranteed  by  the  language  because  it  is  not  possible  for  a program  to  be 
completely  isolated  from  dependencies  on  the  underlying  hardware.  However,  such  dependencies 
are  limited  to  the  attributes  of  the  predefined  numeric  types,  and  properties  of  the  implemented 
real  types  which  cannot  be  derived  from  the  axiomatic  system  (such  as  the  radix  of  the  floating 
point  system). 

To  conclude,  the  numeric  types  in  Green  provide  facilities  clearly  needed  by  the  envisaged  applica 
tions.  A rigorous  axiomatic  system  is  proposed  to  handle  approximate  computation.  Most  impor- 
tantly, portability  and  efficiency  are  not  sacrificed. 


6.  AcceM  Types 


6.1  Introduction 


The  notion  of  access  type  encompasses  the  concept  of  objects  that  are  dynamically  created  during 
the  execution  of  a program.  In  general,  neither  the  number  of  such  objects  in  existence  at  any 
given  time,  nor  the  names  of  those  objects,  can  be  fixed  in  advance. 

The  inclusion  of  such  a feature  in  a language  raises  what  are  traditionally  some  of  the  most  difficult 
issues  in  language  design,  arid  indeed  in  programming.  Accordingly,  the  first  section  of  this  chapter 
is  devoted  to  an  overview  of  the  issues  involved  in  the  area.  This  will  serve  as  background  for  an 
exposition  of  the  approach  adopted  in  the  Green  language  In  many  places  in  this  chapter  we  have 
borrowed  concepts  and  even  wordings  inspired  by  the  Euclid  report. 


6.2  Overview  of  the  Issues 

The  main  problems  usually  encountered  with  access  types  fall  into  two  categories: 

• Conceptual  aspects 

• Reliability,  efficiency,  and  implementation  issues. 

We  first  discuss  these  problems  and  then  define  the  desirable  goals  for  a formulation  of  access 
types. 


6.2.1  Conceptual  Aspects 


Variables  of  a program  can  be  classified  into  two  categories:  static  variables  and  dynamic 
variables. 

Static  variables  are  declared  in  a program  and  are  containers  for  values.  Each  static  variable  has  a 
name  that  is  used  to  denote  either  the  container  or  the  value,  depending  on  the  context  where  the 
name  appears.  The  name  of  a static  variable  is  introduced  by  its  declaration,  together  with  its  type. 
The  variable  exists  during  the  entice  lifetime  of  the  program  unit  to  which  it  is  local.  Such  variables 
are  said  to  be  static  since  their  lifetime  is  determined  by  the  static  structure  of  the  program. 
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In  contrast,  dynamic  variables  are  created  dynamically  without  any  relation  to  the  static  program 
structure,  by  the  execution  of  so  called  allocators  In  general,  the  number  of  dynamically  created 
variables  may  be  unpredictable  and  it  will  be  impossible  to  introduce  all  the  names  of  dynamic 
variables  by  declarations.  Hence  the  internal  name  or  refeience  that  is  produced  by  the  dynamic 
allocation  cannot  be  used  explicitly  to  designate  the  newly  allocated  variable 

To  treat  this  problem,  one  usually  defines  by  declaration  a number  of  indirect  names  that  can  be 
used  to  access  the  internal  names  of  dynamically  allocated  variables  These  indirect  names  are 
variables  that  may  be  used  to  access  the  internal  names  of  different  dynamic  variables  at  succes 
sive  stages  of  execution  Hence,  indirect  names  will  be  called  access  variables  throughout  the 
remainder  of  this  chapter.  Access  variables  can  also  appear  as  components  of  dynamic  variables. 

Four  important  consequences  follow  from  the  fact  that  access  variables  contain  internal  names: 

(1)  Access  variables  may  be  used  to  describe  relations  that  change  over  time. 

(2)  The  same  internal  name  may  be  contained  in  several  access  variables  with  the  consequence 
fhat  thev  enable  access  to  the  same  dynamic  variable. 

(3)  Since  access  variables  may  contain  different  internal  names  at  successive  stages  of  the 
program  execution  a given  dynamic  variable  may  become  inaccessible.  A dynamic  variable 
will  remain  accessible  if  its  internal  name  is  contained  in  a tatically  allocated  access  variable 
or  in  an  access  variable  that  is  a component  of  another  accessible  dynamic  variable 

(4)  Since  an  access  variable  does  not  contain  any  internal  name  until  its  first  allocation  or  assign 
ment,  there  must  be  a special  null  value  corresponding  to  no  internal  name  (non*  in  Simula, 
nil  in  Algol  68  and  Lisp,  null  in  this  language)  This  value  is  also  required  for  describing  partial 
relations. 

Sharing  and  the  possibility  of  inaccessibility  are  thus  two  of  the  classical  difficulties  of  access 
types. 

A third  classical  difficulty  is  the  well-known  problem  of  dereferencing.  Consider  the  name  of  an 
access  variable:  this  name  may  stand  for  (or  provide  access  to)  several  different  things 

• The  name  of  the  (static)  access  variable 

• The  content  of  the  access  variable  (that  is,  its  value:  an  internal  name) 

• The  content  of  the  dynamic  variable  designated  by  this  internal  name 

The  first  two  possibilities  (name  or  content)  also  exist  for  static  variables  Most  languages  (Bliss 
being  the  exception)  have  the  same  notation  in  the  two  cases,  and  make  a distinction  by  context. 
The  third  possibility,  however,  omy  exists  for  access  variables,  and  the  solutions  offered  by 
programming  languages  are  very  diverse. 
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Two  issues  arise: 


(1)  For  assignments,  it  must  be  clear  whether  the  assignment  refers  to  the  access  variables  (ac- 
cess assignment),  or  to  the  dynamic  variables  they  designate  lvalue  assignment).  This  distinc 
tion  is  essential  and  has  been  treated  differently  in  most  languages 

(2)  For  component  selection,  i.e.,  for  denoting  a component  of  a dynamically  created  record,  there 
is  no  possible  ambiguity.  Nevertheless  some  languages  have  chosen  to  make  dereferencing 
explicit  even  in  this  case. 

The  diversity  of  the  solutions  adopted  by  several  languages  is  a clear  indication  of  the  conceptual 
difficulties  involved.  We  illustrate  this  diversity  with  the  following  example,  where  X and  Y are 
access  variables  and  AGE  is  a component  of  the  dynamic  record  variable  (For  the  Algol  68  for- 
mulation. T is  assumed  to  be  the  mode  of  the  record  values;  the  Simula  example  extends  the  pos- 
sibilities offered  for  texts). 


language 

access 

assignment 

value 

assignment 

component 

selection 

Simula 

X Y; 

X :=  Y: 

X AGE 

Algol  68 

X :=  Y; 

T(X)  :=  Y; 

X AGE 

Pascal 

X :=  Y: 

XT  :=  Yt 

XT  AGE 

Green 

X :=  Y: 

X all  :=  Y ad; 

X AGE 

A final  conceptual  difficulty  in  defining  access  types  is  the  notion  of  constant  access  objects  Sup- 
pose the  name  of  an  access  object  is  declared  to  be  constant  Several  alternative  interpretations 
could  be  given  to  such  a declaration. 

(a)  The  access  value  (an  internal  name)  is  constant.  This  means  that  it  always  designates  the 
same  dynamic  object.  The  value  of  the  latter,  however,  could  vary. 

(b)  The  access  value  is  itself  variable,  but  it  may  only  be  used  to  read  the  components  of  a 
designated  object. 

(c)  The  access  value  is  constant  and  it  may  only  be  used  to  read  the  components  of  the 
designated  object.  Note  however  that  we  cannot  infer  that  the  dynamic  object  designated  by 
such  a constant  is  itself  constant  if  other  variables  designate  the  same  dynamic  object 

Some  languages,  including  Mary  |R  74)  and  Lis,  have  provided  alternate  syntaxes  for  all  three 
forms  of  semantics.  The  third  meaning  however  is  the  most  useful  and  hence,  for  the  sake  of 
simplicity,  should  be  retained  as  the  unique  meaning  of  constancy.  Note  that  with  this  semantics, 
an  access  constant  only  has  a read  permit  for  the  components  of  the  designated  object.  Hence  an 
access  constant  cannot  be  assigned  to  an  access  variable  since  a variable  would  have  both  a read 
and  a write  permit  and  only  the  read  permit  can  be  obtained  from  the  constant. 
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6.2.2  Reliability.  Ef  lancy.  and  Implementation  Issues 


When  a dynamic  variable  becomes  inaccessible,  the  corresponding  space  may  at  least  theoretical 
ly  be  recovered  for  other  uses  without  any  risk  This  operation,  classically  called  garbage  collec- 
tion. has  been  used  in  languages  such  as  Lisp.  Simula,  and  Algol  68  It  is  however  rather  costly  and 
cannot  be  used  effectively  for  real  time  systems,  since  it  may  occur  unpredictably  at  critical  times 


For  this  reason  several  languages  in  the  system  programming  area  (including  Lis  and  Euclid)  try  to 
achieve  a better  control  on  the  storage  management  for  dynamic  variables  This  means  that  such 
languages  offer  the  opportunity  to  define  the  workings  of  object  allocation  within  the  language 
itself  Similarly  they  permit  an  explicit  deallocation  statement  which  can  also  be  defined  within  the 
language  itself 


Clearly  such  operations  cannot  be  written  without  violating  strong  typing.  In  addition,  the 
availability  of  explicit  deallocation  opens  the  possibility  of  dangling  access  values,  since  a program- 
mer may  deallocate  a dynamic  variable  whose  internal  name  is  still  contained  by  other  access 
variables 


Confronted  with  this  dilemma  between  reliability  and  efficiency  a possible  answer  is  to  choose 
. eliability  and  to  accept  the  possibility  that  access  types  might  not  be  used  in  programs  that  are 
time  critical  However,  there  are  cases  where  access  types  should  be  used,  precisely  because  the 
application  considered  is  time  critical.  We  illustrate  this  point. 


Assume  that  we  need  to  search  a circular  list  for  an  item  with  a particular  content.  A formulation 
using  an  array  might  look  as  follows. 


subtype  INDEX  is  INTEGER  v 


t tooo 


type  ITEM  is 


SUCC.  PRED  : INDEX 
CONTENT  : INTEGER; 

end  record 


TABLE  array  (INDEX  FIRST 
HEAD.  NEXT  : INDEX: 

SUM  : INTEGER: 


INDEX  LAST)  of  ITEM. 


The  algorithm  for  adding  the  contents  of  the  successors  of  HEAD  may  be  written  as  a while  loop: 


SUM  :=*  0: 

NEXT  :=  TABLE!  HEAD). SUCC; 
while  NEXT  /=  HEAD  loop 

SUM  SUM  ♦ TABLE(NEXT). CONTENT 
NEXT  :=  TABLE(NEXT)  SUCC; 

end  loop. 


Clearly,  the  above  formulation  attempts  to  use  index  values  in  order  to  express  relations  and  does 
not  achieve  this  with  the  elegance  and  readability  offered  by  access  variables.  The  main  point, 
however,  is  that  the  index  computation  involved  in  accessing  the  array  element  TABLE(NEXT)  at 
each  iteration  may  be  a drawback,  especially  on  minicomputers  where  multiplication  is  rather 
slow 


h 


The  alternate  formulation  with  access  variables  (declarations  omitted)  is  given  below: 


SUM  :=.  0. 

NEXT  :=.  HEAD.SUCC; 
while  NEXT  /=  HEAD  loop 

SUM  :=  SUM  ♦ NEXT  CONTENT 
NEXT  :=  NEXT.SUCC; 

end  loop: 


This  solution  is  more  readable  (it  does  not  require  mention  of  names  such  as  TABLE  that  are  irrele 
vant  to  the  logic  of  the  algorithm),  and  also  more  efficient  since  no  index  calculation  is  involved 

In  general,  when  access  variables  are  used  address  computations  will  be  done  once  at  the  time  of 
dynamic  allocation  Thereafter  access  variables  can  only  be  assigned  to  other  access  variables  or 
used  to  access  the  dynamic  variables.  This  however  does  not  involve  address  computations.  On 
the  contrary  when  indices  are  used,  address  computations  must  be  redone  for  every  access 


6.2.3  Goals  For  a Formulation  of  Accass  Types 


As  shown  by  the  previous  example  one  of  the  motivations  for  access  variables  is  efficiency  As  a 
consequence  we  must  be  able  to  use  them  in  time  critical  applications.  In  this  case,  however  we 
must  provide  a form  of  access  variables  that  does  not  result  in  garbage  collection  with  the 
associated  costs  and  unpredictability.  Naturally  this  does  not  exclude  the  possibility  of  more 
elaborate  storage  management  strategies  in  applications  that  are  not  time  critical 

The  needs  of  efficiency  being  thus  satisfied,  it  remains  that  reliability  should  be  a major  goal  in  the 
formulation  of  access  types,  especially  in  view  of  the  conceptual  difficulties  they  raise  A safe  for- 
mulation of  access  types  should  hence  have  several  important  properties: 

• There  must  be  a null  value  for  access  variables.  The  null  value  cannot  be  dereferenced  and  any 
attempt  to  do  so  should  result  in  the  exception  ACCESS_EHROR  (on  many  computers  this  is 
achievable  without  any  runtime  cost  by  selecting  a protected  address  as  the  internal  value  of 

null). 

• Access  variables  should  be  typed  (as  in  Pascal)  so  that  access  variables  can  only  designate 
dynamic  variables  of  a single  type. 

• There  should  be  a language  defined  operation  (the  allocator)  that  creates  a dynamic  object 
and  delivers  its  internal  name,  the  access  value.  On  the  other  hand,  there  should  be  no  opera 
tion  for  explicit  deallocation  of  a dynamic  variable  (to  avoid  dangling  access  values) 

• There  should  be  a clear  distinction  between  access  types  and  other  types.  In  particular,  there 
should  be  no  possibility  for  an  access  variable  to  denote  a static  variable  (again  to  avoid 
dangling  access  values). 
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6.3  Presentation  of 


Ty  PM 


The  presentation  of  the  properties  of  access  types  in  the  Green  language  will  cover  the  following 
topics. 

• How  to  declare  access  types 

• The  collection  of  dynamic  variables  implied  by  the  declaration  of  an  access  type 

• How  to  declare  access  variables  and  constants 

• How  to  allocate  a dynamic  record  variable 

• Component  and  value  assignments 

• Recursive  access  types 

• Procedures  and  functions  with  parameters  belonging  to  an  access  type 

• The  control  of  storage  management  for  a collection  of  dynamic  variables 

6.3.1  Declaration  of  Access  Types  and  Su’jtypes 


Access  variables  like  other  variables  in  the  Green  language  are  typed,  and  belong  to  a so-called 
access  type.  The  example  below  shows  a declaration  of  an  (ordinary)  record  type  followed  by  the 
declaration  of  an  access  type: 

type  PERSON_VALUE  is 

record 

AGE  : INTEGER  range  0 ..  130  ; 

SEX  : (MALE,  FEMALE); 

end  record; 

type  PERSON  is  access  PERSON_VALUE; 

In  this  example.  PERSON_VALUE  is  declared  as  a (static)  record  type.  Hence  static  variables  of 
this  type  can  be  declared  as  usual.  The  access  type  PERSON  is  declared  in  terms  of  the  access 
type  definition  access  PERS0N_VALUE.  This  means  that  access  variables  of  type  PERSON  can 
only  refer  to  dynamically  allocated  record  variables  of  type  PERSON_VALUE. 

It  is  of  course  possible  to  copy  the  value  of  a dynamically  allocated  PERSON_VALUE  into  a static 
variable  of  this  type  and  vice  versa  Note,  however  that  there  is  no  way  for  an  access  variable  of 
type  PERSON  to  designate  a static  variable  of  type  PERS0N_VALUE. 

In  piactice  it  is  not  necessary  to  name  the  type  of  the  dynamic  variables.  Thus  the  previous 
declaration  can  be  achieved  in  a single  step 

type  PERSON  is  access 
record 

AGE  : INTEGER  range  0 ..  130  ; 

SEX  : (MALE.  FEMALE): 

end  record. 
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The  type  of  the  dynamic  variables  can  be  any  type  other  than  an  access  type  itself  For  example  it 
can  be  an  array  type,  as  in 

type  TEXT  ie  acceaa  STRING; 

It  is  possible  to  declare  a subtype  of  an  access  type,  where  constraints  can  be  imposed  ,<n  i ie 
dynamically  allocated  objects  in  the  subtype  declaration  Thus  the  subtype  LINE  defined  below 
corresponds  to  dynamically  allocated  strings  of  80  characters; 

subtype  LINE  is  TEXT  (1  80); 

Note  that  although  it  is  possible  to  imagine  an  access  type  definition  in  a variable  declaration,  such 
a declaration  would  be  rather  useless  In  practice  access  type  definitions  will  always  appear  in 
type  declarations.  Hence  access  types  are  always  named 


6.3.2  Collections  of  Dynamic  Variables 


Conceptually  it  is  important  to  realize  that  each  access  type  declaration  implicitly  defines  a collec 
tion  of  potential  dynamic  variables.  The  actual  collection  will  be  built  during  program  execution  as 
allocators  are  executed  Its  lifetime  cannot  be  longer  than  that  of  the  program  unit  in  which  the 
access  type  definition  is  provided. 

Collections  in  the  Green  language  are  implicit  and  cannot  be  named  (unlike  those  in  early  Pascal, 
Lis.  and  Euclid).  The  collections  associated  with  different  access  types  are  always  disjoint,  i e. . two 
access  variables  of  different  access  types  are  guaranteed  to  contain  the  internal  names  of  dynamic 
records  in  different  collections 

Finally,  the  collection  associated  with  a given  access  type  must  be  considered  as  part  of  the  global 
environment  that  is  accessible  in  the  scope  of  the  access  type  declaration 

6.3.3  Access  Variables.  Allocators,  and  Access  Constants 


Access  variables  are  declared  in  the  usual  way  and  may  be  initialized  in  their  declaration,  for 
instance  with  the  value  of  other  previously  declared  access  variables  or  with  the  specia1  value  null 
representing  no  internal  name.  For  example,  consider 

YOU.  HIM  HER  ; PERSON; 

SOMEONE  : PERSON  :=  null 

An  allocator  creates  a dynamic  variable  and  assigns  its  internal  name  to  an  access  variable; 

YOU  :«  new  PERSON(AGE  =>  30.  SEX  > FEMALE): 

The  allocator  mentions  the  access  type  name  (or  access  subtype  name)  and  contains  an  aggregate 
defining  the  initial  value  of  the  components  of  the  dynamically  allocated  variable 

The  constraints  applicable  to  a dynamically  allocated  object  are  established  when  the  allocator  is 
evaluated  and  cannot  be  modified  during  the  lifetime  of  the  dynamic  object.  In  the  case  of  a 
dynamic  array,  this  means  that  the  bounds  of  such  an  array  cannot  be  modified.  Consider 

MESSAGE  ; TEXT  new  TE\T(1  80  ^ * "): 
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It  is  possible  to  modify  the  character  values  of  the  string  designated  by  MESSAGE,  but  the  bounds 
of  this  String  remain  those  that  are  fixed  at  allocation  tim6,  i.e.  1 and  80 

Similarly,  for  a record  type  with  variants,  the  discriminant  values  established  at  allocation  time 
cannot  be  modified: 

type  BUFFER  ia  access 
record 

LENGTH  constant  INTEGER  range  t 1000 

POS  INTEGER  range  0 1000; 

ALPHA  array  (1  . LENGTH)  of  CHARACTER: 

end  record: 

B BUFFER 

B :=  new  BUFFER  (LENGTH  > 40.  POS  =>  0,  ALPHA  =>  (1  .40  .=> 

The  component  LENGTH  is  a discriminant  used  to  establish  the  upper  bound  of  the  array  ALPHA. 
Hence  the  value  of  LENGTH,  once  initialized  by  the  allocator,  cannot  be  changed  thereafter  (not 
even  by  a global  record  assignment  to  the  dynamic  record  variable)  As  a consequence,  only  the 
size  actually  required  by  the  dynamic  object  need  be  allocated. 

Declarations  of  access  constants  are  given  in  the  usual  way.  The  access  value  (an  internal  name) 
contained  by  an  access  constant  cannot  be  changed,  and  the  constant  name  can  only  be  used  to 
read  the  components  of  the  designated  dynamic  object.  Consider,  for  example,  the  constant 
declarations: 

Y0U_N0W  : constant  PERSON  :=  YOU. 

DAY_NAME  constant  array  (1  7)  of  TEXT 

(now  TEXT('MONOAY').  naw  TEXT! "TUESDAY”),  new  TEXTCWEDNESDAY"), 

new  TEXTCTHURSDAY").  naw  TEXTCFRIDAY”),  naw  TEXT) "SATURDAY”) 

naw  TEXTCSUNDAY')); 

The  constant  Y0U_N0W  contains  the  internal  name  of  the  dynamic  record  designated  by  YOU  at 
the  time  of  the  initialization.  It  means  that  Y0U_N0W  will  always  contain  this  access  value  even  if 
YOU  is  updated  at  a later  time.  Using  the  constant  Y0U_N0W  one  can  read  but  not  modify  the 
components  of  the  corresponding  person.  It  does  not  necessarily  mean  however  that  these  com- 
ponents remain  constant  if  variables  such  as  YOU  are  used  to  modify  the  components 

The  array  DAY_NAME  is  a constant  array,  hence  its  components  are  constant  access  values.  In 
this  case  the  internal  names  associated  with  each  access  constant  are  obtained  from  allocators. 
Since  an  access  constant  cannot  be  assigned  to  an  access  variable,  we  can  infer  that  the 
characters  of  the  strings  denoted  by  DAY_NAME  cannot  be  modified.  Hence  it  would  even  be 
legitimate  for  a translator  to  perform  the  corresponding  allocations  statically  (at  translation  time). 
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6.3.4  Component  Selection,  Indexed  Components  and  Value  Assignment* 


In  the  previous  example,  the  content  of  YOU  is  the  internal  name  of  a dynamically  allocated  record 
variaole.  The  usual  syntax  of  component  selection  is  used  as  if  YOU  were  the  record  variable  itself 
(i.e  dereferencing  is  implicit  for  component  selection): 

YOU.AGE  - a variable  of  type  INTEGER 

YOU  SEX  — a variable  of  type  (MALE  FEMALE) 

Similarly,  we  can  use  the  normal  selection  syntax  to  designate  the  entire  (dynamic)  record  object 
Thus  YOU. all  is  an  object  of  type  PERSON_VALUE  such  that  the  following  condition  is  true: 

YOU  all  = (AGE  =>  YOU.AGE.  SEX  =>  YOU  SEX): 

This  notation  can  also  appear  in  an  allocator  as  in  the  assignment  statement 

HER  :=  naw  PERSON(YOU.all); 

Finally  the  same  notation  may  be  used  for  value  assignments.  Remember  that  if  YOU  and  HER 
contain  internal  names  of  dynamically  allocated  record  variables,  then  after  the  assignment 

YOU  :=  HER; 

the  two  access  variables  contain  the  same  internal  n?me.  In  contrast  the  value  assignment  for 
copying  the  value  of  the  dynamic  record  designated  by  HER  into  the  dynamic  record  designated 
by  YOU  is  written 

YOU.sll  :=  HER  sll; 

Such  value  assignments  are  always  possible  between  dynamic  record  variables  without  variants. 
With  variants  they  are  legal  only  if  the  discriminants  of  the  variables  are  identical.  This  must  be 
checked  (in  many  cases  at  execution  time). 

Indexed  components  for  arrays  denoted  by  access  types  arr  written  exactly  as  in  the  case  of  static 
arrays  (this  means  that  dereferencing  is  also  implicit  for  indexing)  Thus  we  can  write 

MESSAGE(I)  ;= 

MESSAGEO  1 ..  16)  :=  DAY_NAME(  1 )( 1 .6): 

MESSAGE(2 1 ..  27)  :=  "MORNING"; 

Note  finally  that  the  notation  X.all,  denoting  the  dynamic  object  designate  oy  X ran  be  used  for 
all  dynamic  objects,  v ! rher  they  are  records,  arrays,  or  scalars 
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6.3.5  Recursive  Access  Types 


1 


As  stated  earlier,  the  components  of  a dynamic  record  can  be  of  any  type,  including  dynamic  types 
This  introduces  the  possibility  of  recursive  access  types  with  components  designating  dynamic 
records  of  the  same  collection  As  an  example,  the  access  type  PERSON  may  be  extended  as  fol 
lows 

type  PERSON  is  acceas 
record 

AGE  : INTEGER  range  0 130; 

SEX  ; (MALE.  FEMALE); 

SPOUSE  PERSON. 

end  record 

The  variable  HIM  SPOUSE  can  be  assigned  another  PERSON  variable: 

HIM  SPOUSE  HER 

Furthermore,  HIM  SPOUSE. AGE  is  an  INTEGER  variable,  HIM. SPOUSE  SPOUSE  is  a variable  of 
type  PERSON,  and  so  forth. 

This  kind  of  recursion  in  access  type  declarations  may  involve  more  than  one  access  type.  In  such 
cases  it  is  first  necessary  to  provide  an  incomplete  declaration  of  any  access  type  whose  name  is 
mentioned  before  the  occurrence  of  its  full  declaration.  This  is  shown  by  tho  following  pair  of 
access  types: 

type  CAR.  incomplete  prodeclaration  of  CAR 

type  PERSON  ie  access 
record 

NAME  : SIRING; 

AGL  : INTEGER  range  0 130: 

SEX  (MALE.  FEMALE); 
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6.3.6  Accoss  Objects  Parameters 


Like  other  variables,  access  variables  can  be  used  as  parameters,  and  parameter  modes  have  their 
usual  meaning.  Moreover,  one  must  bear  in  mind  that  an  access  constant  can  only  be  used  to  read 
the  components  of  the  object  designated  by  the  contained  internal  name  This  rule  also  applies  to 
in  parameters.  Hence  if  components  of  an  access  parameter  must  be  updated,  it  must  be  declared 
with  the  mode  in  out. 

For  functions,  the  parameters  must  as  usual  be  in  parameters.  In  addition  the  collection  of  objects 
so  far  allocated  must  also  be  considered  as  an  implicit  in  parameter  of  the  function.  Consequently, 
it  is  not  possible  to  modify  a component  of  a dynamic  record  within  the  function.  Similarly,  it  is  not 
possible  to  evaluate  an  allocator  for  this  access  type  within  the  function. 

This  does  not  prevent  assignments  of  local  access  variables  and,  more  generally,  operations  on 
access  types  local  to  the  function.  As  an  example  consider  the  declarations  for  the  lists  of  section 
6.2.2. 

type  ITEM  is  access 
record 

SUCC,  PRED  : ITEM; 

CONTENT  : INTEGER; 

end  record: 

A function  CARDINAL  counting  the  elements  in  a given  circular  list  can  be  written  as  follows: 

function  CARDINALfHEAD:  ITEM)  return  INTEGER  is 
— The  head  is  not  counted  as  a list  element 
- For  an  empty  list  HEAD.SUCC  = HEAD.PREO  = HEAD 

NEXT  : ITEM  :=  HEAD.SUCC; 

COUNT  : INTEGER  :=  0: 

begin 

while  NEXT  /=  HEAD  loop 
NEXT  :=  NEXT. SUCC; 

COUNT  :=  COUNT  + 1; 

end  loop 
return  COUNT 
end: 

Note  that  assignment  to  the  local  access  variable  NEXT  does  not  modify  the  collection  of  ele- 
ments. Note  also  that  the  components  of  the  dynamic  records  may  be  read,  such  as  in  NEXT.SUC- 

! c' 

When  allocatois  have  to  be  executed,  value  returning  procedures  (or  just  procedures)  must  be 
used. 


6.3.7  Storage  Management  for  Accesa  Types 


Unless  specified  otherwise  the  collection  of  dynamic  objects  issociated  with  an  access  type  will 
be  allocated  in  a global  heap  (and  may  be  garbage  collected  in  some  implementations}.  For  time 
critical  applications,  however,  it  is  possible  to  specify  an  upper  bound  for  the  space  needed  for  a 
given  collection  The  corresponding  space  can  then  be  reserved  globally  when  the  access  type 
definition  is  elaborated.  Subsequently,  when  leaving  the  program  unit  enclosing  the  access  type 
definition,  the  space  corresponding  to  the  collection  may  be  recovered  since  the  contained  objects 
are  no  longer  accessible  Such  an  upper  bound  is  indicated  by  a length  specification: 

MAJC.NUM  constant  INTEGER  1000: 

for  PERSON  use  MAX  NUM*PERSON  SIZE: 

The  expression  provided  after  the  reserved  word  use  is  the  size  in  bits  of  the  storage  area  to  be 
reserved  for  the  collection  of  persons.  Naturally  if  we  have  an  estimate  of  the  maximum  number  of 
persons  (MAX  NUM)  to  be  allocated,  the  expression  should  be  formulated  with  the  attribute  PER 


A collection  for  which  such  a length  specification  has  been  given  behaves  as  a (static)  array  in  so 
far  as  storage  allocation  is  concerned  The  objects  are  allocated  within  this  static  storage  area  by 
allocators,  and  remain  allocated  until  the  collection  disappears  when  leaving  the  program  unit 
where  the  access  type  definition  appears.  The  exception  STO RAG E_0VER FLOW  is  raised  when 
the  space  reserved  is  exhausted 

Such  collections  may  be  allocated  either  on  the  stack  or  on  the  heap.  They  have  several  advan- 
tages In  terms  of  storage  management  they  have  a cost  comparable  to  that  of  arrays.  In  addition 
they  offer  both  the  notational  advantages  and  the  addressing  efficiency  of  access  variables. 
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7.  Subprograms 


Subprograms  can  be  functions  or  procedures  The  form  of  these  program  units  is  quite  traditional, 
following  from  Algol  60.  Nevertheless  the  design  of  a subprogram  facility  raises  difficult  issues  in 
terms  of  the  organization  of  the  program  text,  the  definition  of  the  parameter  mechanism,  the 
nature  of  functions  and  overloading.  These  issues  are  discussed  in  separate  subsections 


7.1  Subprogram  Declarations  and  Subprogram  Bodias 


The  textual  representation  of  subprogram  bodies  is  largely  classical  as  shown  in  the  example 
below: 

procedure  PUSH(E  in  ELEMENT_TYPE;  S : in  out  STACK)  it 

begin 

if  S. INDEX  = S SIZE  then 
raise  STACK_OVERFLOW. 

else 

S. INDEX  :=  S. INDEX  + 1; 

S.SPACEIS  INDEX)  :=  E; 

end  if; 
end  PUSH; 

However,  the  Green  language  allows  the  subprogram  declaration  to  be  separated  from  the  sub- 
program body.  As  an  example,  the  subprogram  declaration 

procedure  PUSHIE  : in  ELEMENT_TYPE;  S : in  out  STACK), 

may  appear  grouped  with  other  subprogram  variable,  constant,  and  type  declarations  in  a given 
declarative  part,  whereas  its  body  may  appear  later  in  the  list  of  bodies  of  the  declarative  part 

The  main  reason  for  permitting  such  separation  is  'eadability.  If  the  body  and  the  specification 
appear  together  (as  in  Algol  60),  the  potentially  large  body  is  mixed  with  the  smaller  interface 
specification.  The  specification  may  be  hard  for  the  reader  to  find,  especially  when  examining  a 
program  with  a large  number  of  subprograms  spread  over  several  pages  of  text.  In  addition,  an 
isolated  variable  declaration  between  two  large  subprograms  is  a well-known  source  of  error  in 
Algol  60  (the  neglected  variable  may  hide  an  outer  variable  that  is  in  consequence  never  updated). 
These  inconveniences  are  avoided  in  the  Green  language  In  a declarative  part  the  following  ele 
ments,  if  present,  appear  in  this  order: 
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• list  of  declarations 

• list  of  representation  specifications 

• list  of  bodies 

The  user  has  thus  the  option  to  regroup  all  subprogram  declarations  within  a small  space  of  text 
thereby  prov.dmg  an  immediate  overview  of  all  subprograms  that  are  local  to  a given  scope  In 
addition,  the  above  syntax  forbids  the  declaration  of  a variable  between  two  subprogram  bodies 
since  the  bodies  appear  last. 

The  split  of  the  subprogram  declaration  from  its  body  is  a convenience  for  large  subprograms  but 
it  is  a necessity  for  subprograms  declared  in  the  visible  part  of  a package,  and  fo,  subprograms'that 
are  mutuaHy  recursive.  Requiring  a split  in  all  cases,  including  small  subprograms,  would  however 
add  verbosity  without  compensating  advantages.  In  the  Green  language  the  decision  to  split  is 
therefore  left  to  the  programmer,  except  in  the  cases  just  mentioned  where  it  is  necessary. 

Although  this  important  textual  issue  is  left  to  the  programmer,  no  semantic  problems  are  involved 
body  thB  mforma,,on  prov,ded  bv  the  subprogram  declaration  is  repeated  in  full  in  the  subprogram 


7.2  Parameter  Modes 


Three  parameter  modes,  in.  out.  and  in  out  are  provided  in  the  Green  language.  These  modes  are 
defined  in  terms  of  their  abstract  behavior  (i.e.  without  referring  to  their  implementation)  as  fol- 


in  Within  the  subprogram,  the  parameter  acts  as  a local  constant  whose  value 

is  provided  by  the  corresponding  actual  parameter, 

out  Within  the  subprogram,  the  parameter  acts  as  a local  variable;  its  value 

is  assigned  to  the  corresponding  actual  parameter  as  a result  of  the 
execution  of  the  subprogram. 

in  out  Within  the  subprogram,  the  parameter  acts  as  a local  variable,  and  permits 
access  and  assignment  to  the  corresponding  actual  parameter. 

For  each  parameter  mode,  the  implementation  may  choose  to  provide  access  to  the  corresponding 
actual  parameter  either  (a)  throughout  the  call  (i.e.  by  reference ) or  (b)  by  copying  it  before  or  after 
the  call,  or  both,  as  appropriate;  before  the  call  for  in  parameters,  upon  return  for  out  parameters 
both  for  in  out  parameters. 

This  translator  choice  may  be  influenced  by  the  size  of  the  objects  considered.  For  large  objects  an 
implementation  by  reference  is  often  more  efficient.  On  the  other  hand,  for  objects  that  are  smaller 
than  the  machine  s addressable  storage  units,  copying  will  usually  be  more  efficient. 


aPr°bleT  °f  8CC8SS  t0  SmaM  obieCtS  is  indeed  severe  and  ™v  be  illustrated  by  the  problem  ot 
the  access  to  parameters  which  are  boolean  components  of  records.  Although  such  components 

bitV^sL”mwithin8a  ,Sd  AN'  iS  9U'r‘"'"*  ,h8'  ’heV  ato8vs  be  ,°u"d  in  “™ 

The  two  known  alternatives  to  copying  in  the  case  of  in  out  parameters  are  equally  unacceptable 

• One  might  associate  an  implicit  subprogram  (a  thunk)  with  each  actual  boolean  parameter 
This  is  both  complex  and  inefficient. 

* £?^r9ht'  " I"  P8SCal  f°rbid  comP°nents  of  P0ckRd  rec°r<*°  as  actual  parameters  for  in  out 
formal  parameters,  and  adopt  otherwise  a standard  representation  for  -til  small  objects  for 
example  each  boolean  component  on  an  addressable  storage  unit.  The  problem  with  this  solu 
t.on  is  that  for  all  practical  purposes  it  would  force  programmers  to  use  representation 
specifications  in  too  many  cases;  the  translator's  choice  being  too  often  unacceptable  except 
on  machines  with  small  addressable  units.  In  addition,  the  program  validity  would  depend  on 
whether  or  not  a representation  specification  were  given. 

In  norma/  situations  the  semantics  of  a program  will  not  be  affected  by  the  fact  that  parameter 
passing  is  implemented  by  reference  or  by  copying.  The  abnormal  situations  are: 

(a)  Shared  variables; 

Consider  the  subprogram 

procedure  P(X  : in  T); 

and  assume  that  the  implementation  has  chosen  to  implement  parameter  passing  by 
reference.  Then  a call  P(S)  where  S is  a shared  variable  must  be  compiled  with  some  precau 
t.on.  The  code  of  the  procedure  P relies  on  the  fact  that  X is  constant  and  this  might  not  be  the 
case  for  a shaired  variable  such  as  S.  The  solution  in  this  case  is  to  create  a local  copy  of  S on 
the  calling  side: 

local_copy  :=  S; 

P(locaLcopy); 


Exceptions 

If  a subprogram  execution  is  abnormally  terminated,  by  an  exception,  then  out  and  in  out 
parameters  may  have  been  updated  if  implemented  by  reference,  and  will  be  unchanqed  if 
implemented  by  copying. 

It  would  certainly  be  possible  to  complicate  the  runtime  exception  executor  so  that  copyinq 
back  of  current  values  is  achieved  in  case  of  termination  by  an  exception,  but  it  is  not  worth 
the  price.  Consider  for  example: 


i 


procedure  P|X  : out  INTEGER)  ie 
begin 

- (1) 

X := 

- (2) 

end; 


P(U); 


If  P is  abnormally  terminated  by  an  exception,  the  only  information  that  the  caller  has  is  the 
nature  of  the  exception.  He  does  not  usually  know  whether  it  occurred  during  (1)  or  (2)  or 
even  during  the  result  assignment.  So  the  uncertainty  introduced  by  not  knowing  the 
implementation  is  of  the  same  order  as  the  uncertainty  that  already  exists  about  the  exact 
point  of  the  exception.  In  addition,  when  a user  writes  P(U)  where  U is  an  out  parameter,  he 
expects  the  value  of  U to  be  changed.  So  it  does  not  matter  much  if  this  value  is  changed  dur 
ing  the  call  or  only  at  the  end.  If  the  user  wants  to  reuse  the  previous  value  of  U in  the  case 
that  P is  terminated  by  an  exception,  the  only  logical  way  to  do  so  is  to  assign  its  value  to 
another  variable  before  the  call. 


(c)  Aliasing 


If  illegal  aliasing  is  used  then  the  results  may  differ  for  reference  implementations  and  copy 
implementations.  For  example  consider 


procedure  P(X  ; 
berjin 

X :=  X + 1; 
X :=  X + A; 

end; 


in  out  INTEGER)  is 


Since  A is  accessed  within  the  body  of  P,  a call  such  as  P( A)  would  be  illegal  since  there 
would  be  two  possible  access  paths  to  A (directly  or  through  the  parameter  X).  Assuming  A = 
2 before  a call  P( A),  the  value  of  A upon  return  would  be  5 for  an  implementation  by  copying 
and  6 for  an  implementation  by  reference. 

These  are  the  only  possible  cases  where  reference  and  copy  implementations  might  differ.  The 
problem  with  shared  variables  can  be  solved  by  creating  local  copies.  For  exceptions  nothing  need 
be  done  since  the  uncertainty  introduced  is  of  the  same  order  as  the  usual  uncertainty  about  the 
localization  of  the  exception.  Some  cases  of  aliasing  will  be  detected  by  the  compilers  but  some 
more  complex  cases  must  remain  undetected.  In  any  case  aliasing  is  a programming  error.  Any 
program  containing  such  an  error  may  deliver  different  results  (but  erroneous  ones  in  any  case)  on 
different  machines. 

During  this  design  we  considered  (and  rejected)  several  alternative  views  to  this  abstract  formula- 
tion of  the  parameter  passing  modes.  For  example  an  implementation  oriented  formulation  of 
modes  could  be  defined  in  terms  of  the  mechanisms  involved,  i.e.  copying  or  reference.  However,  if 
the  same  capabilities  are  to  be  offered  it  leads  to  more  modes  (constant  by  copying,  constant  by 
reference,  variable  by  copying  before  and  after,  variable  by  reference,  result  by  copying,  result  by 
reference).  Although  only  a subset  of  them  might  be  provided,  it  is  critical  for  reliability  and 
efficiency  to  be  able  to  pass  an  array  by  reference  and  nevertheless  deny  the  right  to  modify  its  ele- 
ments. Apart  from  its  complexity,  such  a formulation  would  force  the  programmer  to  think  in 
terms  of  (and  be  aware  of)  the  representation  of  objects,  and  would  therefore  compromise  por- 
tability. 
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We  consider  the  formulation  of  the  parameter  passing  modes  in.  out.  and  in  out  in  terms  of  their 
abstract  behavior  to  be  much  simpler  and  preferable  Programs  that  rely  on  some  assumption  con 
cerning  the  implementation  of  parameter  passing  modes  are  erroneous 


7.3  Parameter  Pasting  Conventions 


Two  parameter  conventions  need  to  be  considered.  The  usual  positional  notation  is  almost  univer- 
sal. However,  with  more  than  three  or  four  parameters  it  is  hard  to  follow  the  text,  and  not  even 
the  parameter  mode  is  apparent.  Following  several  authors  |Fr  77.  Har  76.  IRHC  74|  and  common 
usage  in  many  control  languages,  the  Green  language  also  permits  an  alternative  form  of 
parameter  passing  in  which  the  associations  are  specified  on  a name  basis.  Placing  the  formal 
parameter  on  the  left  and  the  corresponding  actual  parameter  on  the  right  of  a parameter  associa- 
tion it  is  possible  to  provide  more  readable  procedure  calls.  These  provide  knowledge  of  the 
parameter  modes,  and  hence  of  the  possible  side  effects  on  an  actual  parameter,  such  as  on  MY 
FILE  below: 


CREATEIFILE  :=:  MY_FILE.  NAME  "finaltext  Feb.  1 5"): 

Where  long  parameter  lists  are  common  and  have  default  values,  such  as  in  the  job  control  area 
this  form  of  named  parameter  associations  provides  especially  high  readability.  It  may  be  used  in 
conjunction  with  the  default  value  facility  available  for  an  in  parameter  if  no  explicit  value  is 
provided  within  the  call. 


As  an  example,  a simulation  package  may  declare  the  procedure  ACTIVATE  as  follows: 


procedure  ACTIVATE!  PROCESS 
AFTER 
WAIT 
PRIOR 


in  PROCESS_NAME; 
in  PROCESS_NAME  NO  PROCESS 
in  TIME  :=  0.0: 
in  BOOLEAN  FALSE); 


As  shown  in  this  declaration,  the  parameter  PROCESS  must  be  provided  in  all  calls  (because  no 
default  value  is  given).  On  the  other  hand  the  parameters  AFTER.  WAIT  ana  PRIOR  may  be  omit 
ted.  Thus  the  two  following  calls  of  ACTIVATE  are  equivalent: 


ACTIVATE! PROCESS  X,  AFTER  :=  NO  PROCESS.  WAIT  : 0 0 PRIOR  FALSE) 

ACT  IVATEIPROCESS  X): 


Clearly  in  many  contexts  the  order  of  parameters  is  either  highly  conventional  (such  as  for  coor 
dinate  systems)  or  immaterial  (such  as  in  MAX(X.Y)).  Hence  the  Green  language  admits  both  con 
ventions.  The  classical  positional  convention  may  be  used  whenever  the  programmer  feels  that 
named  parameters  would  add  verbosity  without  any  gain  in  readability 


The  two  conventions  may  also  be  used  concurrently,  with  positional  parameters  appearing  first 
that  is,  once  naming  is  used  the  rest  of  the  call  must  use  naming.  This  allows  the  default  value 
mechanism  to  be  used  even  when  a positional  notation  is  desirable  as  in  the  following  graph  plot- 
ting and  simulation  examples: 


MOVE_PEN(X1.  Y 1 . LINE  :=  THICK); 
MOVE_PEN(X2.  Y2.  PEN  :=  UP); 


ACTIVATE(X); 

ACTIVATED,  AFTER  : Y): 

ACTIVATED.  WAIT  50  0.SEC0NDS  PRIOR  TRUE) 
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As  shown  in  this  last  example,  the  naming  conventions  may  be  used  in  conjunction  with  the 
default  parameters  to  provide  a high  degr  e of  expressivity  and  readability  that  could  only  be 
ach.evcd  at  the  expense  of  a predefined  syntax  for  the  activate  primitive  in  Simula  |DNM  69|. 


7.4  Function  Subprograms 


The  purpose  of  a function  is  to  calculate  a value.  This  is  the  conventional  mathematical  meaning  of 
a function  Small  functions  to  access  complex  data  structures  are  an  essential  feature  of  modern 
software.  Such  functions  can  not  only  hide  irrelevant  parts  of  the  data  structure  but  can  provide  a 
cleaner  interface  to  the  outside  world. 

Although  the  mathematical  origin  of  the  function  concept  is  clear,  its  incorporation  into  a program- 
ming language  can  lead  to  several  different  solutions  depending  on  the  operations  that  are  allowed 
on  variables.  Different  levels  of  restrictions  can  be  considered  leading  to  different  concepts  of  func- 
tions: 

(1)  Reading  global  variables  is  not  allowed. 

(2)  Reading  global  variables  is  allowed  but  updating  them  is  not. 

(3)  Updating  global  variables  is  allowed  provided  that  the  subprogram  is  not  called  at  points 
where  these  variables  are  visible. 

!4)  Updating  global  variables  is  allowed  without  restrictions. 

The  first  level  corresponds  to  the  mathematical  notion  of  function:  there  are  no  implicit  parameters 
in  the  form  of  global  variables.  Consequently  two  function  calls  with  the  sarrK  arguments  always 
deliver  the  same  result.  However,  the  class  of  cases  in  which  such  functions  an  be  used  is  rather 
limited  and  does  not  justify  its  identification  as  a feature  of  a programming  language 

The  second  level  is  more  common,  and  it  also  has  interesting  mathematical  properties  that  can  be 
used  for  code  optimization.  For  example,  if  F and  G are  two  such  functions  delivering  results  of  a 
given  type  (assuming  * to  be  commutative): 

F +-  F is  equal  to  2 * F 
F * G is  equal  to  G * F 

Functions  of  this  form  are  provided  in  the  Green  language.  They  are  indicated  by  the  reserved  word 
function  in  their  declaration.  For  example: 

function  CARDINAUHEAD  : ELEMENT)  return  INTEGER: 

Such  functions  must  not  have  side  effects.  This  requires: 
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(a)  no  update  of  global  variables. 

(b)  only  parameters  with  in  mode. 

(c)  no  call  to  procedures  which  update  globals.  directly  or  indirectly. 

(d)  no  updating  of  components  of  access  variables. 

(e)  no  allocation  statement  within  a function  body. 

These  checks  can  be  performed  by  the  translator.  For  procedures  it  requires  checking  that  the  cal- 
led procedures  have  the  same  no-side-effect  property  in  a transitive  manner.  The  main  difficulty  is 
for  separately  compiled  procedures. 

This  form  of  functions  may  not  perform  input-output  since  this  is  a side-effect.  One  may  object  that 
this  prevents  instrumentation  and  debugging  of  such  functions.  A pragmatic  attitude  must  be 
taken  here.  It  is  to  be  expected  that  the  environment  of  tools  developed  around  this  language  will 
provide  facilities  for  instrumentation  and  for  tracing  values.  Such  facilities  can  be  specified  as 
pragmas  recognized  by  the  translator  and  hence  their  actions  will  not  be  considered  as  side 
effects. 


The  third  level  is  illustrated  by  subprograms  such  as  random  number  generators  or  memo  func- 
tions, which  modify  their  environment.  This  is  provided  in  the  Green  language  by  value  returning 
procedures,  i.e.  by  procedures  whose  specifications  include  a result: 

procedure  DRAWICHANCES  : REAL  range  0.0  ..  1.01  return  BOOLEAN 

Such  procedures  may  be  called  within  expressions  and  obviously  do  not  have  the  aforementioned 
properties  of  functions.  For  example: 

DRAWI0.5)  or  DRAWI0.5) 

is  not  necessarily  equal  to  DRAW(0.5).  Calls  to  value  returning  procedures  within  an  expression 
are  evaluated  in  the  order  in  which  they  appear.  Such  calls  are  not  allowed  in  expressions  defining 
the  constituents  of  types  or  of  constraints. 

The  fourth  level,  with  arbitrary  side-effects,  would  undermine  the  advantages  of  the  functional 
approach  to  software.  In  addition  it  would  complicate  the  semantics  of  all  language  constructs 
where  expressions  involving  such  calls  may  occur.  Hence  this  form  of  functions  is  not  provided. 


7.5  Overloading 

At  any  point  in  a program,  several  subprograms  declared  with  the  same  identifier  or  operator  sym- 
bol may  be  visible,  without  hiding  each  other  as  would  be  the  case  for  variables  with  the  same 
identifier.  Such  subprograms  (and  their  identifier  or  operator  symbol)  are  said  to  be  overloaded. 
Overloading  of  subprograms  with  the  same  designator  (the  identifier  or  operator)  is  possible  if  the 
subprogram  specifications  are  different  in  other  respects.  For  identical  specifications  the  usual 
rules  of  redeclaration  apply:  redeclaration  in  a nested  unit  hides  the  outer  declaration:  redeclara- 
tion is  not  allowed  within  the  same  declarative  part. 

Overloading  is  also  possible  for  literals.  An  enumeration  literal  may  denote  values  of  different 
enumeration  types;  a number  may  belong  to  several  numeric  types.  For  example,  1 .5  may  denote  a 
value  of  a fixed  point  type  or  a value  of  a floating  point  type 
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There  are  several  reasons  for  permitting  these  forms  of  overloading.  Above  all,  the  careful  use  of 
overloading  can  be  a valuable  asset  for  readability  since  it  offers  an  additional  degree  of  freedom 
for  the  choice  of  suggestive  identifiers  that  convey  the  properties  of  the  entities  they  denote. 

Most  programming  languages  already  use  the  same  symbol  " + " to  denote  addition  for  integer 
values  and  for  floating  point  values  (although  addition  is  not  commutative  for  floating  point  types 
because  of  the  approximate  nature  of  computations)  Since  addition  has  similar  properties  for 
rational  and  for  complex  numbers,  it  is  only  natural  to  reuse  the  same  operator  when  defining 
these  two  types.  Similarly,  it  is  natural  to  use  the  same  name  for  an  output  operation  such  as  PUT, 
whether  it  is  used  for  an  argument  of  type  integer,  real  or  character,  or  for  a user  defined  type. 

Extension  or  overloading  of  the  meaning  of  an  operator  is  in  general  quite  valuable  for  user  defined 
types.  Such  types  will  normally  be  defined  in  packages  together  with  their  associated  operations. 
The  writers  of  these  packages  can  certainly  not  foresee  all  possible  uses.  In  particular  they  may  not 
(and  should  not)  be  aware  of  the  fact  that  these  packages  are  used  in  contexts  where  some  opera- 
tions appear  as  overloaded.  The  writers  should  be  free  in  their  choice  of  suggestive  names  but  the 
users  should  not  be  burdened  by  inconvenient  choices  over  which  they  have  no  influence. 
Overloading  achieves  this  separation.  Similar  arguments  apply  for  overloading  of  enumeration 
literals 

Overloading  of  subprograms  and  overloading  of  enumeration  literals  are  therefore  allowed  in  the 
Green  language.  On  the  other  hand,  overloading  of  names  is  not  provided  for  other  entities  such  as 
variables,  constants,  types,  etc.  As  we  shall  see,  the  identification  of  occurrences  of  overloaded 
subprograms  uses  the  contextual  information  provided  by  the  types  of  variables  and  constants. 
Uniqueness  of  type  in  the  case  of  variables  and  constants  is  thus  essential,  to  permit  this  iden- 
tification. It  is  moreover  not  clear  that  much  would  be  gained  by  allowing  such  additional  forms  of 
overloading  (the  effect  of  an  overloaded  constant  can  be  achieved  by  a parameterless  function). 
Overloading  of  type  names  would  lead  to  unsolvable  ambiguities;  for  example,  T(X)  could  either  be 
a qualified  expression  or  a function  call. 

The  remainder  of  this  section  analyzes  the  identification  process  and  redeclarations.  We  conclude 
by  comments  on  the  good  usage  of  overloading. 


7.5.1  Identification  of  Overloaded  Constructs 


When  an  overloaded  identifier  appears  at  a given  point  of  the  text,  the  identifier  itself  does  not 
provide  enough  information  to  identify  a unique  meaning.  In  such  cases  contextual  information 
must  be  used  to  select  the  unique  meaning,  and  the  occurrence  is  ambiguous  if  this  information  is 
not  sufficient.  This  problem  arises  for  the  following  language  constructs: 

• literals 

• aggregates 

• calls  of  parameterless  functions 

• calls  of  subprograms  with  parameters 

• calls  of  subprograms  defined  in  packages  or  tasks 
and  made  visible  via  a use  clause. 
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By  contextual  information  we  mean  information  derived  from  the  context  where  these  constructs 
are  used,  such  as  the  type  of  a variable  to  which  a literal,  an  aggregate,  or  a function  is  assigned,  or 
the  types  of  the  actual  parameters  of  a subprogram  call.  Whenever  this  information  is  not  sufficient 
the  programmer  must  provide  explicit  qualification  (for  example  by  a qualified  expression).  The 
extent  to  which  this  is  required  depends  upon  the  particular  rules  adopted  for  overloading.  We  dis- 
cuss these  alternative  rules  using  the  following  example: 

function  -*-(X.  Y : COMPLEX)  return  COMPLEX: 

function  '.’(A  : INTEGER;  Y : COMPLEX)  return  COMPLEX; 

function  '.-(Y  : COMPLEX;  A : INTEGER)  return  COMPLEX. 

First  consider  the  variable  declarations 

C.  D : COMPLEX; 

I.  J : INTEGER; 

M,  N : LONGJNTEGER; 

Expressions  including  a «"  operator  such  as 

C * 0 
I . J 
I * C 
M * N 

are  unambiguous  since  the  type  of  both  operands  is  known  and  can  be  used  to  identify  the  cor- 
responding operator  specification.  But  now  take  the  following  cases: 

(a)  INTEGER(3*5); 

(b)  I :=  3*5; 

(c)  C ;=  l*3*D; 

(d)  C :=  3*5*0; 

(e)  C :=  3*(  1 .5); 


Several  alternative  overloading  rules  can  be  considered. 

Rule  1 : 

The  types  of  the  parameters  must  be  sufficient  for  the  identification. 

This  rule  requires  a single  bottom-up  traversal  (from  leaves  to  root)  of  the  trees  associated  with 
expressions.  It  is  the  rule  used  in  Algol  68.  This  rule  permits  the  identification  of  “*"  in  case  (c)  but 
not  in  the  other  cases,  because  (for  example)  the  type  of  3 is  not  determined. 

Rule  2: 

The  types,  modes,  and  names  of  the  parameters  must  be  sufficient  for  the  identification. 

This  rule  would  permit  the  additional  identification  of  subprograms  and  aggregates  with  named 
associations  For  the  above  example,  only  case  (c)  is  identified. 


■ ) 
i 
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Hule  3 : 


The  types,  modes,  and  names  of  the  parameters,  together  with  the  result  type,  must  be  sufficient 
for  the  identification  Here  the  desired  type  derived  from  the  context  is  first  propagated  down  the 
tree  associated  with  the  expression,  then  the  bottom-up  traversal  is  performed. 

As  examples  of  this  influence  of  context:  the  type  of  the  variable  on  the  left-hand  side  of  an  assign- 
ment is  the  desired  type  for  the  right-hand  side;  the  type  given  in  a qualified  expression  is  its 
desire  type,  the  type  of  a formal  parameter  of  an  identified  subprogram  is  the  desired  type  of  the 
corresponding  actual  parameter  This  rule  resolves  cases  (a),  lb),  Ic).  It  does  not  resolve  cases  Id)  or 
(e)  since  none  of  the  occurrences  of  can  be  completely  resolved. 

In  order  to  explain  this  we  shall  use  the  notation  of  qualified  expressions  and  express  the  mul- 
tiplication in  functional  form  (MUL  is  used  instead  of  We  use  ? to  denote  an  undefined 
qualification  To  assist  the  eye  contents  of  widely  separated  parentheses  have  been  dropped  by 
one  line  For  example  case  (cl  can  be  expressed  as 

C :=  COMPLEX! 

MULI  . 

INTEGER(  >.COMPLEX(D) 

MULI  ) 

INTEGERU)  INTEGERI3) 

* 

On  the  other  band,  case  (d)  corresponds  to 

C :=  COMPLEXI  * ,. 

MULi  , 

7I  I.COMPLEX(D) 

MUH>(3l  ><511 

Note  that  since  the  result  type  is  also  taken  into  account,  parameterless  functions  may  be 
overloaded  For  example.  EMPTY  can  be  defined  for  several  user  defined  types.  Similarly  functions 
may  also  be  considered  to  be  attributes  of  a type  on  the  basis  of  their  result  type,  not  only  on  the 
basis  of  their  parameter  tyoes:  a more  intuitive  rule. 

Hule  4 


The  types  modes  and  names  of  the  parameters,  together  with  the  result  type  must  be  sufficient 
for  the  identification  The  contextua,  information  propagated  first  top-down  and  then  bottom-up  in 
the  expression  tree  can  consist  of  a set  of  alternative  types. 

For  this  rule  the  set  of  alternative  types  for  a parameter  is  propagated  top-down.  These  alternative 
types  correspond  to  the  types  given  in  all  specifications  that  match  the  (set  of)  desired  result 
typelsL  During  the  subsequent  bottom-up  propagation  it  must  be  possible  to  identify  all  opera- 
tions. This  rule  resolves  case  td).  Consider  for  example  the  top-down  propagation  (we  qualify  an 
expression  by  a set  of  types,  or  by  the  type  itself  if  it  is  unambiguous).  This  gives: 

C :=  COMPLEXI  ,. 

MULI  , 

S’ I ),COMPLEX(D) 

MUL(S2(3).S3(5)I 

where  the  sets  are  as  follows:  SI  = S2  = S3  = (INTEGER,  COMPLEX) 
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In  the  subsequent  bottom  up  propagation  this  desired  type  information  is  sufficient  to  determine 
that  3 and  5 are  of  type  INTEGER  thus  resolving  the  statement  as: 

C :=  COMPLEX! 

MUU  , 

INTEGER!  ),  COMPLEX(D) 

MUU  ) 

INTEGER(3).INTEGER(5) 

Rule  5: 


The  types,  modes,  and  names  of  the  parameters,  together  with  the  result  type  must  be  sufficient 
for  the  identification.  The  contextual  information  is  propagated  both  ways  repeatedly  until  con- 
vergence. 

For  this  rule,  the  identification  is  a success  if  every  sei  of  desired  types  has  a unique  member  at 
convergence.  Otherwise  the  expression  is  ambiguous.  This  rule  identifies  case  (e): 

C :=  3*(1 ,5); 

After  the  first  top  down  pass  we  have 

C :=  COMPLEX!  ). 

MUL(  I 

S 1 (3),  S2(  ) 

<?<1>,  ?(5» 

where  the  sets  SI  and  S2  are  defined  as 
SI  = S2  = IINTEGER.  COMPLEX! 

After  the  first  bottom  up  pass  we  are  able  to  identify  the  literal  3,  thus  leading  to: 

C :=  COMPLEX!  )■ 

MUU  ) 

INTEGER(3),S2(  ) 

( ?!  1 ),?(5)) 

A second  top  down  pass  now  permits  in  succession  the  identification  of  the  multiplication  opera- 
tion, the  qualification  COMPLEX  of  the  aggregate,  and  the  types  of  the  components. 

C :=  COMPLEX! 

MUU  I 

IN-rEGER(3).COMPLEX<  ) 

(INTEGER(1  |,INTEGER(5)I 

For  practical  purposes,  only  the  last  two  rules  would  seem  to  be  sufficient.  The  algorithm  implied 
by  the  fifth  rule  could  in  theory  be  rather  time-consuming.  However,  in  practice  most  expressions 
are  rather  small  and  convergence  towards  a definition  (or  towards  ambiguity)  should  be  rather  fast 
in  view  of  the  fact  that  named  constants  and  variables  is  the  usual  case. 
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Th«  mn|or  reason  f or  adopting  this  fifth  nils  in  the  Green  language,  however.  is  not  so  much  the 
additional  power  (Hint « qualification  may  be  used  for  more  readability)  but  rather  the  simplicity  of 
its  statement.  In  effect  this  rule  is  the  only  one  for  which  the  following  statement  is  true: 

The  typos,  mottos  and  nemos  of  the  parameters  together  with 
the  result  type  must  be  sufficient  for  the  identification 

Tha  additional  details  about  propagation  need  not  be  stated  if  It  is  sufficient,  it  can  he  done  in  this 
manner  or  in  any  other  manner 


7.5.2  Redeclaration  of  Subprograms 


The  problem  of  determining  whether  a subprogram  declaration  is  a redeclaration  ol  a prioi  sub 
program  declaration,  is  closely  connected  to  the  previously  discusser)  identification  of  overloaded 
subprogram  calls. 

The  rule  adopted  for  overloading  uses  all  availab|e  information,  including  tiro  type  of  parameters 
ami  result  their  names,  and  modes  (also  order  foi  positional  associations).  As  a consequence  a 
subprogram  declaration  is  a redeclaration  only  if  all  calls  are  ambiguous.  If  only  part  of  the  calls  arc 
ambiguous  the  declaration  is  an  overloading.  In  any  case  ambiguous  calls  can  n'ways  bo  detected 


7.5.3  Overloading  of  Operators 


As  stated  earlier  good  usage  of  overloading  can  contribute  to  readability  by  allowing  suggestive 
identifiers  to  be  user)  However  as  with  any  other  facility  overloading  could  be  misused  For  exam 
pie  the  language  definition  does  not  (and  cannot)  prevent  a user  from  declaring  a GET  function 
that  actually  performs  an  output  operation  In  general  it  cannot  prevent  the  choice  of  names  that 
give  the  wrong  connotation 

This  danger  is  particularly  apparent  for  operators  since  the  cot  responding  symbols  convey  a well 
defined  mathematical  meaning.  Users  are  therefore  stiongly  advised  to  preserve  the  usual  axioms 
that  rpply  to  the  predefined  operators.  The  language  only  permits  overloading  of  to  deliver  a 
result  of  type  BOOLEAN  Similarly.  / is  Interpreted  as  the  predefined  opposite  of  and  hence 
cannot  be  overloaded  directly  On  tire  other  hand,  the  same  danger  exists  foi  other  operators,  foi 
example  the  relational  operators  v v . \ n and  the  user  should  exercise  extreme  care  in  such 
casus  Separate  overloading  of  the  operator  v,  , for  example,  may  permit  a more  efficient 
implementation  than  would  be  derivable  by  combining  sepai  ate  implementations  of  v.  and 

We  believe  that  the  language  designer  should  not  forbid  an  otherwise  useful  facility,  on  the 
grounds  that  it  could  be  misused  In  isolated  cases  He  should  never  take  the  attitude  of  the 
Nowspoak  (Or  501  designer: 

Don  t you  see  that  the  whole  aim  of  Newspeak  is  to  narrow  the  tenge 
of  thought  i In  the  end  we  shall  mnke  thought  crime  impossible,  because 
theta  will  be  no  words  in  which  to  express  it." 

Rather  fie  should  always  strive  to  expand  the  expressive  power  of  the  language  while  at  the  same 
time  providing  more  safety  by  the  consistency  of  his  design. 
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8.1  Motivation 


Modules  allow  the  programmer  to  group  logically  related  items  together.  They  cover  a wide  family 
of  uses,  ranging  from  collections  of  common  declarations,  to  groups  of  subprograms  and  encap- 
sulated data  types.  The  Green  language  provides  two  forms  of  modules  called  packages  and  tasks, 
with  similar  properties.  Tasks  are  the  form  of  modules  used  for  parallel  processing.  This  discussion 
of  modules  is  presented  essentially  in  terms  of  the  package  form,  although  the  same  considera- 
tions generally  apply  to  tasks.  Tasks  are  further  discussed  in  Chapter  11. 

The  ability  to  package  declared  entities,  such  as  subprograms,  data  elements,  types,  and  other 
modules,  provide  the  basis  for  a powerful  structuring  tool  for  complex  programs 

Moreover,  modules  permit  clear  delineation  of  the  amount  of  information  accessible  to  the  rest  of 
the  program  on  the  one  hand,  and  the  information  that  must  remain  internal  to  the  module  on  the 
other  hand.  The  internal  information  is  hidden  and  thereby  protected  from  deliberate  or  inadvertent 
use  by  other  programmers.  This  serves  not  only  to  localize  the  effect  of  errors  internal  to  the 
module,  but  also  to  increase  the  ease  with  which  one  implementation  of  the  module  may  be 
replaced  by  another.  Because  of  this  second  aspect,  modules  are  also  an  essential  tool  for  program 
modularity,  supporting  information  hiding  [Pa  7 1 1,  and  program  verification. 

Facilities  for  modularization  have  appeared  in  many  languages.  Some  of  them  such  as  Simula 
|DNM  69|,  Clu  (Li  74,  LSA  77],  and  Alphard  |WLS  76|  provide  dynamic  facilities  which  may  entail 
extensive  run-time  overhead. 

The  facility  provided  in  the  Green  language  is  more  static,  in  the  spirit  of  previous  solutions  offered 
in  the  Modula  |Wi  76|,  Euclid  (LHLMP  76],  Lis  |IRHC  74.  IF  77|  and  Mesa  |GMS  77|  languages.  At 
the  same  time  it  retains  the  best  aspects  of  solutions  in  earlier  languages  such  as  Fortran  and 
Jovial. 


The  solution  provided  here  combines  powerful  facilities  which  nevertheless  remain  efficiently 
implementable  within  the  state  of  the  art. 

We  shall  first  discuss  packages  informally  by  means  of  examples  (section  8.2).  We  then  discuss  a 
number  of  important  technical  issues  addressed  during  the  design  of  the  language  (section  8 3). 


8.2  Informal  Introduction  to  Package* 

Packages,  as  provided  in  the  Green  language,  are  a major  tool  for  program  modularity.  We 
recognize  three  bn  id  forms  of  modularization  that  can  be  achieved  by  different  uses  of  modules: 
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(1)  Named  collection  of  declarations 

Logically  related  variables,  constants,  and  types  to  be  used  in  other  program  units. 

(2)  Groups  of  related  subprograms. 

Logically  related  functions  and  procedures  which  share  internal  own  data  tvoes  and  <u,h 
ST  wTuse  tU0rsTm°I  Term  Ca"6d  3 

(3)  Encapsulated  data  types: 

™ ‘:s£zz:t7 in  such  8 "•»  ,ha' ,he 

bv'the  mSteTh," E be,W<r  ,h6Se  'h'ee  ,0,mS  iS  ,he  a™u"<  °<  'nforrnation  hiding  pro,ided 

<zbzz™°z:~ig  r moduie  ,herebv 

Zo^lT^Z:'  d d°f I"1'  aeclara,ions  l*>P«Klin8  on  thoTfot  theTifdowl  Ire 

“ rsr  r 

(1)  Named  collection  of  declarations : 

The  module  exposes  all  of  its  declarations  (all  declarations  can  be  seen  through  the  window!. 
,2)  Groups  of  related  subprograms: 

The  module  exposes  the  declarations  of  the  externally  accessible  subprograms  (only  these  can 
betseen  through  the  window!  but  hides  the  declaration  of  interna.  variab,™ and  oSocal 

(3)  Encapsulated  data  types: 

enc^psltd  TXf  ^ ^ ^ types  be 

There  is  no  critical  linguistic  difference  between  these  thrpp  ratPnnrioc  =r.w 

thT  jh!eembroaadefde9ree  °f  inf°;mation  hidin9-  However,  to  present  the  ideas' sim^we^culs 
the  three  broad  forms  separately,  with  appropriate  examples. 


8-2.1  Named  Collection  of  Declarations 


sTTTrTrLaradm^naLUS,L0f  CO,,ections  of  tables  * as  communication  areas,  where 

application,  the  following  mo^^ec^at^  6Xamp,e'  in  8 Simp,e  graphic 
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package  PLOTTING_DATA  la 
PEN_UP  : BOOLEAN: 

CONVERSION  FACTOR. 

X_OFFSET.  Y_OFFSET 
X_MIN,  X_MAX, 

Y_MIN.  Y_MAX  : REAL; 

X_VALUE,  Y_VALUE  : artayll  500)  of  REAL; 
and  PLOTTING_DATA: 

The  elaboration  of  this  module  consists  of  the  elaboration  of  its  constituent  variable  declarations. 
Elaboration  takes  place  in  the  context  where  the  package  declaration  appears  te  tually.  Thus  in 

terms  of  the  lifetime  of  the  constituent  variables  (PEN_UP Y_VALUE),  everything  happens  as  if 

their  declarations  were  inserted  in  the  place  of  the  declaration  of  the  package  PLOTTING_DATA. 

However,  when  a package  declaration  is  elaborated,  the  constituent  variables  are  not  yet  directly 
accessible.  In  any  context  where  the  module  declaration  can  be  seen  it  is  possible  to  acquire 
access  to  these  variables  by  dot  notation.  For  example  we  could  write  rtatements  such  as 

PLOTTING_DATA.PEN_UP  :=  TRUE, 

PLOTTING_DATA.X_VALUE1 1 0)  :=  PLOTTING_DATA.X_MIN; 

It  is  also  possible  to  acquire  access  to  these  variables  by  means  of  a use  clause  of  the  form 

um  PLOTTING_DATA; 

The  effect  of  a use  clause  is  to  make  a set  of  names  known  locally.  The  names  and  their  meanings 
are  defined  in  the  designated  module.  In  this  fashion,  with  a use  clause,  one  may  selectively 
acquire  access  to  an  entire  group  of  declarations.  As  an  example,  the  previous  statements  can  be 
rewritten  as 

declare 

use  PI  OTTING_DATA; 

Dtyin 

PEN_UP  :=  TRUE: 

X_VALUE  (10)  :=  X_MIN; 

end; 


This  simple  form  of  package  corresponds  almost  exactly  to  the  notion  of  named  common  in 
Fortran.  There  are  however  three  crucial  differences  between  this  use  of  packages  and  Fortran 
named  common  blocks; 

(1)  A module  can  be  declared  in  any  nested  block  or  program  unit,  so  long  as  its  declaration  is 
then  visible  to  all  program  units  requiring  access  to  the  module.  By  contrast,  in  Fortran  all 
named  common  blocks  are  effectively  global  to  the  main  program. 

(2)  Storage  reservation  for  a module  (as  a consequence  of  (1 ) above)  may  be  performed  at  scope 
entry  time  for  a module  that  is  not  global  to  the  entire  program.  By  contrast,  the  storage  space 
for  a Fortran  named  common  block  is  always  reserved  throughout  the  entire  program  execu- 
tion. 


i 
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13)  The  contents  of  a module  is  defined  only  once,  in  the  context  of  its  declaration.  Within  the 
scope  of  the  declaration,  it  is  then  possible  to  acquire  access  to  that  entire  set  of  entities,  in  as 
many  program  units  as  necessary,  merely  by  mentioning  the  name  of  the  given  module  in  a 
use  clause  (even  in  the  case  of  separately  compiled  units).  For  Fortran  named  common  blocks 
on  the  other  hand,  the  specification  must  be  replicated  in  its  entirety  in  each  context  where 
access  to  the  constituents  is  required.  The  need  to  replicate  information  in  this  fashion  is 
generally  recognized  as  a violation  of  the  principles  of  modularity,  as  an  inconvenience  and  as 
a serious  source  of  errors. 


A similar  class  of  modules  is  for  groups  of  constant  declarations,  for  example 

package  METRIC-CONVERSIONS  it 

CM_PER_INCH  : constant  REAL  ;=  2.54; 

CM_PER_FOOT  ; constant  REAL  ;=  3048, 

CIVLPER_YARD  : constant  REAL  :=  91.44, 

KM-PER-MILE  : constant  REAL  :=  1.609344; 
end  METRIC-CONVERSIONS, 

\ 

More  generally,  in  a typed  language,  groups  of  declarations  are  likely  to  include  logically  related 
types,  along  with  constants,  and  variable  declarations  as  shown  in  the  next  example 

package  WORK_DATA  is 

type  DAY  is  (MON,  TUE,  WED,  THU,  FRI,  SAT,  SUN); 
type  DURATION  is  delta  0.01  range  0.0  ..  24.0; 

type  TIME-TABLE  is  array  (MON  ..  SUN)  of  DURATION; 

WORK-HOURS  : TIME-TABLE; 

NORMAL-HOURS  : constant  TIME-TABLE  := 

(MON  ..  THU  =>  8.25,  FRI  =>  7.0,  SAT  | SUN  =>  0.0); 

end  WORK-DATA; 


In  all  three  examples  we  achieve  the  same  effect:  the  elaboration  of  the  module  creates  the  cor- 
responding entities  (whether  a constant  a variable,  or  a type),  but  they  are  not  yet  externally  visi- 
ble. Accessibility  is  only  obtained  by  dot  notation  or  by  a use  clause.  In  a unit  with  a use  clause  for 
W0RK_DATA.  it  is  possible  to  declare  variables  of  type  DURATION,  and  to  update  the  array 
WORK-HOURS,  or  to  read  the  constants  of  NORMAI HOURS.  Thus  we  may  have: 


declare 


use  WORK-DATA; 

TODAY  : DAY; 

HOURS  : DURATION; 

begin 

— compute  HOURS  and  TODAY 

if  HOURS  > NORMALHOURS  (TODAY)  then 

HOURS  :=  HOURS  + 2.0  * (NORMALHOURS(TODAY)  - HOURS); 

end  if; 


WORK-HOURS  (TODAY) 

end; 


HOURS; 


i 


-J 
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8.2.2  Groups  of  Related  Subprograms 


The  second  major  use  of  modules  is  for  the  creation  of  groups  of  related  subprograms.  For  exam 
pie,  it  may  be  desirable  to  make  a package  of  the  mathematical  routines  (SIN,  COS,  LOG,  EXP,  ...) 
for  the  reason  that  a user  needing  one  of  them  is  very  likely  to  need  the  others  too.  Moreover,  the 
routines  may  share  common  subprograms  (sometimes  elaborate)  which  should  not  be  accessible 
to  the  user 

Declaring  such  functions  within  a module  MATH_LIB  is  preferable  to  having  them  as  predefined 
functions  in  the  standard  envi-onment.  Thus,  a user  who  is  not  dealing  with  numerical  computa- 
tions does  not  have  to  import  MATH_LIB.  and  his  name  space  will  not  be  congested  by  names  that 
are  useless  to  him. 

We  next  consider  the  example  of  a package  of  random  number  generators,  since  it  will  enable  us 
to  point  out  other  important  possibilities.  The  structure  of  this  package  is  already  more  elaborate 
than  the  form  used  for  collections  of  common  declarations.  It  is  made  of  two  parts  which  together 
define  the  module.  The  first  part  is  the  module  specification: 

package  RANDOM  la 

— visiule  part  : declarations  of  sampling  functions 
and  RANDOM. 

This  describes  the  visible  part  of  the  package,  that  is,  the  declarations  that  become  directly  acces- 
sible in  a context  containing  a use  clause  for  RANDOM.  In  this  case,  the  user  interface  contains  the 
declarations  of  the  sampling  functions  DRAW.  RANDJNT  and  UNIFORM.  It  also  includes  the 
procedure  SET_SEED  used  to  initialize  the  seed  of  the  random  number  generator,  and  the  excep- 
tion ERROR.  Consequently  the  user  may  decide  to  provide  a local  handler  for  ERROR. 

The  second  part  of  the  module  is  the  module  body.  This  is  the  hidden  part  of  the  module:  none  of 
the  entities  contained  therein  are  accessible  outside  the  module  (both  use  clauses  and  selected 
components  only  give  access  to  items  of  the  visible  part).  The  structure  of  the  package  body  is  as 
follows: 

package  body  RANDOM  la 

— hidden  date  and  subprogram  bodies 
begin 

--  initialization  part 
end  RANDOM: 

The  two  variables  SEED  and  CO_SEED  (like  all  variables  of  a module  that  are  not  local  to  inner 
subprograms)  are  own  variables.  They  are  initialized  by  the  initialization  part  of  the  module  and 
retain  their  value  between  calls  of  the  sampling  functions.  In  languages  which  do  not  have  this 
facility  for  hiding  own  variables,  the  seed  must  either  be  global,  or  be  passed  as  a parameter  to  the 
sampling  procedures;  in  either  case  it  is  therefore  known  outside  the  module. 

The  package  body  also  contains  the  bodies  of  the  sampling  procedures,  and  that  of  the  procedure 
CONGRUENCE  for  generating  the  next  random  number.  This  procedure  is  purely  local  and  is  not 
part  of  the  user  interface  (it  is  not  declared  in  the  visible  part).  Hence  it  can  only  be  called  within 
the  module  body  of  RANDOM  by  the  sampling  functions. 
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package  RANDOM  i« 

procaduia  SET-SEED  (START  : INTEGER); 

procedure  DRAW  (CHANCES  : REAL  range  0.0  ..  1.0)  return  BOOLEAN 
procedure  RANDJNT  (LOW.  HIGH  : INTEGER)  return  INTEGER- 
procedure  UNIFORM  (LOW.  HIGH  : REAL)  return  REAL; 

ERROR  ; exception; 
end  RANDOM; 

package  body  RANDOM  is 
SEED  : INTEGER; 

CO_SEED  : REAL; 

procedure  CONGRUENCE  is 

LAMBDA  : constant  INTEGER  :•=  8#12_571_342_215; 

begin 

~EED  :=  INTEGER((LONG_INTEGER(SEED)*LONGJNTEGER(LAMBDA))  mod  2**32) 

CO-SEED  :^=  REAL(SEED)  / REAL  (2*<32); 

end; 

procedure  SET_SEED(START  : INTEGER)  is 

begin 

SEED  :=  START; 

CONGRUENCE; 

end; 

procedure  DRAW(CHANCES  REAL  range  0.0  ..  1.0)  return  BOOLEAN  is 

begin 

CONGRUENCE; 

return  CO-SEED  < CHANCES; 

end; 

procedure  RAND_INT(LOW,  HIGH  ; INTEGER)  return  INTEGER  is 

begin 

if  LOW  > HIGH  then  raise  ERROR;  end  if 
CONGRUENCE; 

return  LOW  + INTEGER(CO_SEED  * REAL(HIGH  - LOW  + 1))- 

end: 


procedure  UNIFORM(LOW,  HIGH  : REAL)  return  REAL  is 
begin 

if  LOW  > HIGH  then  raise  ERROR;  end  if 
CONGRUENCE; 

return  LOW  + CO_SEED*(HIGH  - LOW); 

end 

begin 

— package  initialization  ; 

SET-SEED(I); 
end  RANDOM; 
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The  separation  of  the  two  parts  of  a module  (the  module  specification  and  the  module  body)  is  very 
clear.  In  general  the  two  parts  need  not  be  textually  contiguous  and  they  may  even  be  compiled 
separately.  In  this  way  the  separately  compiled  module  body  Is  not  only  protected  but  physically 
hidden. 

In  a language  with  type  declarations  such  as  the  Green  language,  packages  developed  for  user 
applications  are  likely  to  contain  not  only  procedures  but  also  type  declarations.  As  an  example, 
consider  the  package  RATIONAL-NUMBERS. 

package  RATIONAL-NUMBERS  is 
type  RATIONAL  is 
'•cord 

NUMERATOR  : INTEGER; 

DENOMINATOR  : INTEGER  range  1 ..  INTEGER  LAST; 

and  record 

function  '='  (X.Y  : RATIONAL)  return  BOOLEAN; 

function  “+*  (X,Y  : RATIONAL)  return  RATIONAL; 

function  (X.Y  : RATIONAL)  return  RATIONAL, 

end; 

package  body  RATIONAL-NUMBERS  is 

procedure  SAME_DENOMINATOR  (X.Y  : in  out  RATIONAL)  is 

Dtgm 

--  reduces  X and  Y to  the  same  denominator 

end; 


function  (X.Y  : RATIONAL)  return  BOOLEAN  is 

U.V  : RATIONAL; 

1-— — 1— 

D#yin 

U :=  X; 

V :=  Y: 

SAME-DENOMINATOR  (U.V); 

return  (U. NUMERATOR  = ENUMERATOR); 

end  '=■; 

function  •+'  (X.Y  : RATIONAL)  return  RATIONAL  Is  ...  end 
function  (X.Y  : RATIONAL)  return  RATIONAL  is  ...  snd 

end  RATIONAL-NUMBERS; 

The  type  RATIONAL  is  declared  within  the  visible  part  of  the  package  In  a context  containing  a 
use  clause  for  RATIONAL-NUMBERS,  it  is  possible  to  declare  variables  of  type  RATIONAL  and 
apply  the  operators  and  to  thorn.  It  is  also  possible  to  operate  directly  on  the  compo 

nents  of  a rational  number  and  to  construct  rational  values  as  record  aggregates. 

As  in  the  previous  example,  the  bod'js  of  these  functions  are  provided  in  the  module  body,  which 
also  declares  the  local  procedure  SAME-DENOMINATOR.  This  procedure  modifies  the 
denominators  (and  numerators)  of  its  arguments.  By  encapsulation,  usage  has  been  confined  to 
the  bodes  of  the  three  public  functions,  where  proper  precautions  can  be  taken  (for  example, 
copying  the  arguments  X and  Y of  "=’  in  the  local  variables  U and  V before  calling 
SAME-DENOMINATOR). 
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8.2.3  Encapsulated  Data  Typas 


In  the  previous  package  examples,  the  hiding  of  declarations  and  subprogram  bodies  within  the 
module  body  ensured  that  no  outside  program  unit  could  affect  these  local  entities.  In  this  simple 
model,  entities  were  either  public  (if  declared  in  the  visible  part)  or  totally  hidden  (if  declared  in  the 
module  body). 

Encapsulated  data  types  correspond  to  a situation  in  which  we  want  the  name  of  a type  to  be 
public,  but  where  the  knowledge  of  its  internal  properties  is  to  be  available  only  to  the  subprogram 
bodies  contained  in  the  module  body. 

This  encapsulation  is  achieved  by  declaring  the  type  name  within  the  visible  part  (since  the  type 
name  should  be  available  to  users  of  the  module),  but  at  the  same  time  specifying  the  type  to  be 
private.  Its  full  definition  is  then  provided  in  a private  part  following  the  visible  part. 

As  an  example  of  encapsulated  data  type,  consider  the  following  skeleton  of  an  input  output 
package  declared  as  follows: 

package  SIMPLE_INPUT_OUTPUT  is 

type  FILE_NAME  it  private; 

NO_FILE  : constant  FILE.NAME; 
procedure  CREATE  return  FILE_NAME; 

procedure  READ  (ELEM  : out  INTEGER:  F : in  FILENAME); 
procedure  WRITE  (ELEM  : in  INTEGER;  F : in  FILE_NAME); 

l 

private 

type  FILE_NAME  is  new  INTEGER  0 ..  50; 

NO_FILE  : constant  FILE_NAME  :=  0; 
end  SIMPLE_INPUT_OUTPUT; 

In  the  visible  part  given  above,  the  type  FILE_NAME  is  declared  as  private.  External  to  the  module 
it  is  possible  to  declare  variables  of  the  type,  but  the  properties  of  objects  of  this  type  are  kept 
private.  Hence  the  only  thing  a user  can  do  with  file  names  is  to  assign  them  to  other  file  name 
variables  or  to  pass  them  as  parameters  (mainly  to  the  procedures  READ  and  WRITE)  once  they 
are  obtained  by  calling  the  procedure  CREATE. 

The  full  definition  of  the  private  type  FILE_NAME  and  that  of  the  private  constant  N0_FILE  are 
given  in  the  private  part  (the  declarative  part  following  the  reserved  word  private).  A module  body 
for  the  above  package  is  sketched  as  follows: 

package  body  SIMPLEJNPUT_OUTPUT  it 

type  FILE_DESCRIPTOR  is  record  ...  end  record; 

DIRECTORY  : array  (FILE_NAME)  of  FILE_DESCRIPTOR; 

procedure  CREATE  return  FILE_NAME  is  ...  end; 

procedure  READ  (ELEM  ; out  INTEGER;  F : in  FILE.NAME)  is  ...  end; 

procedure  WRITE  (ELEM  ; in  INTEGER;  F : in  FILE.NAME)  is  ...  end; 

begin 

end  SIMPLE_INPUT_OUTPUT; 
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Within  the  body,  file  names  are  integers  indexing  an  internal  directory  declared  as  an  array. 
However  an  external  user  of  the  module  cannot,  for  instance,  do  any  arithmetic  on  file  names 

With  the  above  definition  of  the  type  FILE.NAME,  the  user  still  has  the  possibility  of  assigning  file 
names  and  also  of  comparing  them  for  equality  and  inequality.  These  possibilities  are  even  denied 
in  the  following  variation  of  the  previous  package: 

package  SAFEJO  i« 

restricted  type  FILE.NAME  is  private. 

procedure  CREATE  IF  In  out  FILENAME); 
procedure  READ  (ELEM  out  INTEGER.  F : in  FILE.NAME! 

procedure  WRITE  (ELEM  : in  INTEGER.  F : in  FILE  NAME)' 

private 

type  FILE.NAME  is 
record 

CONTENT  : INTEGER  :=  0; 
end  record: 
end  SAFE.IO: 

A user  of  this  module  can  only: 

• declare  variables  of  type  FILE.NAME.  the  use  of  a reco.d  type  containing  initial  values 
provides  implicit  initialization  of  such  variables. 

• pass  these  objects  to  the  operations  supplied  by  the  package  SAFE.I0 

• pass  them  as  parameters  of  other  procedures.  For  example,  it  is  possible  to  write  the  following 

procedure  M 


procedure  TRANSFER  .ITEM  (F.G  : in  FILE.NAME)  is 
E : ELEM. 
begin 

READ  (E.F): 

WRITE  (E.G); 

end; 


neither  assignment  nor  comparison  of  file  names  are  possible,  it  is  unnecessary  to  define  a 
null  file  in  this  formulation.  Moreover,  CREATE  can  no  longer  be  a value-returning  procedure  since 
' ^ould  not  be  assigned  to  the  destination  variable.  Note  also  that  the  parameter  mode  for 
CREATE  has  been  changed  to  in  out  thus  permitting  us  to  check  whether  it  is  overwriting  an 
existing  file  name.  M 

For  the  more  classical  examples  of  encapsulated  data  types  (from  the  current  literature),  the  reader 
is  referred  to  chapter  1 3 of  this  document  (a  generic  definition  of  the  type  queue)  and  to  section 
3 of  the  reference  manual  (a  generic  definition  of  the  type  stack) 


8.3  Technical  Iiwm 


The  design  ot  modules  involves  nearly  all  aspects  of  the  language  The  most  significant  in  this  con- 
text are 

• Visibility  control  and  information  hiding 

• Relation  to  separate  compilation 

• Instantiation  and  initialization  of  modules 

• Access  to  the  properties  of  types  defined  within  modules 

• Instantiation  and  Initialization  of  objects  of  private  types. 

Other  interact. ons  will  be  discussed  in  the  chapters  on  program  structure  and  visibility,  on  parallel 
processing,  on  separate  compilation,  and  on  generic  units. 


8.3.1  Visibility  Control  and  Information  Hiding 

The  scope  rules  of  traditional  block  structure  are  inadequate  for  the  reliable  construction  of  large 
programs  Declarations  in  nested  blocks  allow  entities  of  outer  blocks  to  be  accessed  by  all  inner 
blocks,  whereas  one  needs  more  precise  control  over  the  visibility  of  declarations  Another  severe 
limitation  of  block  structure  is  the  inability  to  declare  a variable  (or  any  other  name)  accessed  by  a 
limited  set  of  subprograms  without  making  the  variable,  at  least  potent  ally,  accessible  for  other 
subprograms  also. 

Modules  give  the  programmer  precisely  this  kind  of  control.  The  corresponding  visibility  rules  are 
'iCussed  in  the  chapter  on  program  structure  In  this  chapter  we  concentrate  on  the 
aracteristics  of  modules  that  are  essential  for  visibility  control  and  information  hiding. 

“'hr  n defining  a module  the  visible  part  states  which  declarations  are  potentially  accessible  out- 
sioo  the  module.  This  identifies  the  window  in  the  wall  surrounding  the  module  mentioned  above. 

Any  other  program  unit  within  the  scope  of  the  module  can  potentially  access  the  visible  part,  but 
does  not  do  so  automatically.  In  order  to  get  actual  access,  either  a use  clause  must  be  provided, 
or  names  in  the  form  of  selected  components  (dot  notation!  must  be  written 

Thus,  access  to  the  identifiers  declared  in  the  visible  part  is  selective.  Names  declared  in  the  visible 
part  of  a module  do  not  automatically  pollute  the  name  space  of  the  rest  of  the  program.  Access  to 
the  identifiers  declared  in  the  module  body  is  even  more  controlled.  Access  is  available  only  within 
the  module  body,  in  particular  to  the  bodies  of  the  subprograms  declared  in  the  visible  part. 

The  other  essential  characteristic  of  modules  in  this  language  is  the  textual  separation  of  the  inter- 
face. 


? a module  consists  of  all  relevant  declarations  for  a user  of  the  module  In  the  solu- 
h«  t!  , r!d  GJeen  ,an9ua9e  8,1  declarations  are  textually  separated  from  the  rest  of 

h Thf V °T  " 3t  'S  Ca"ed  ,h®  ViS'b,e  part  of  the  module  This  textual  separation  is  a sign.fi- 
cant  advantage  for  readability  and  for  information  hiding. 

Other  languages  such  as  Euclid  and  Modula  have  used  a solution  involving  an  export  list  mention- 
mg  all  identifiers  constituting  the  module  interface  This  means  that  either  all  meanings  of  an 
overloaded  identifier  are  exported,  or  none  of  them.  Moreover  it  also  means  that  in  order  to  know 
die  properties  of  these  identifiers,  the  human  reader  must  scan  through  the  entire  text  of  the 
module.  This  is  a tedious  operation  and  is.  in  addition,  a breach  of  information  hiding  principles 
since  . involves  reading  parts  of  the  text  which  should  be  of  no  concern  (and  may  not  even  be 
available)  to  the  user. 


8.3.2  Influence  of  Separate  Compilation 


The  essential  role  of  modules  is  for  logical  modularity.  However  they  also  have  a useful  roe  in 
physical  modularity  in  terms  of  separate  compilation.  These  two  criteria  for  program  modulariza- 
t.on  lead  to  slightly  different  requirements,  and  the  design  of  modules  takes  both  into  account 
Beth  require  modules  to  have  a clearly  defined  interface  but  physical  modularity  requires  an  inter- 
face containing  more  information  than  for  logical  modularity. 

Extra  information  is  needed  to  allow  the  compiler  tc  deal  with  variables  of  private  types  seen  from 
a separately  defined  module.  For  this  reason  the  private  part  belongs  to  the  physical  interface 

From  the  point  of  view  of  logical  modularity,  the  physical  interface  is  irrelevant  to  all  other 
modules,  since  they  should  not  be  concerned  with  the  physical  representation  of  the  encapsulated 
types^  But  in  order  to  permit  separate  compilation,  it  is  necessary  for  any  module  specification  to 
provide  sufficient  information  to  allow  the  compiler  to  handle  declarations  of  variables  of  an 
encapsulated  type. 

The  difference  essentially  concerns  storage  allocation.  A type  declaration  implicitly  defines  the 
amount  of  storage  needed  for  each  variable  of  the  type.  A module  defining  a type  must  therefore 
mention  the  entire  structure  of  the  type  so  that  the  appropriate  amount  of  space  can  be  reserved 
This  information  (and  also  any  representation  specification  for  the  type)  must  be  part  of  the 

physical  interface  of  the  module.  Otherwise  any  change  will  require  that  all  dependent  modules  be 
recompiled.  5 w 

To  summarize,  the  logical  interface  corresponds  to  the  visible  part  the  physical  interface  corres- 
ponds to  the  complete  module  specification,  that  is.  tc  both  the  visible  and  the  private  part. 

As  long  as  a module  specification  s not  changed,  the  module  body  that  implements  this  specifica- 
hon  can  be  defined  and  redefined  without  affecting  other  units  using  this  specification  as  interface 
to  the  module.  Hence  it  is  possible  to  compile  a module  body  separately  from  its  module  specifica 
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8.3.3  Instantiation  and  Initialization  of  Modules 


Each  package  declaration  results  in  a single  instance  of  the  corresponding  package.  This  instance 
is  created  when  the  package  is  elaborated.  As  a consequence,  the  space  needed  for  the  objects 
declared  in  the  package  (both  in  the  package  specification  and  in  the  package  body)  is  allocated 
Whenever  such  an  object  declaration  specifies  an  initialization,  it  is  performed. 

More  .elaborate  initializations,  which  cannot  be  specified  by  expiessions  but  require  the  execution 
of  statements,  can  be  included  in  the  sequence  of  statements  following  the  (optional)  reserved 
word  bogin  in  the  package  body.  The  execution  of  this  (optional)  sequence  of  statements  com- 
pletes the  elaboration  of  the  package.  An  exception  handler  provided  at  the  end  of  these  state- 
ments applies  for  exceptions  raised  during  the  elaboration  of  the  package  declaration. 

Multiple  instances  of  a module  can  be  obtained  if  the  module  is  generic.  In  this  case  the  module 
specification  includes  a generic  clause  and  individual  instances  are  created  by  generic  instantia- 
tion 

Elaboration  of  a task  body  is  performed  differently.  Elaboration  is  performed  when  an  initiate  state- 
ment for  the  task  is  executed.  This  is  discussed  further  in  the  chapter  on  tasking. 


8.3.4  Note  on  Visibility 


If  a use  clause  is  provided  within  a given  program  unit,  it  opens  the  visibility  of  the  visible  part  of 
each  named  module  in  a non-transitive  manner.  Thus,  if  a use  clause 

use  M; 

is  given  in  the  visible  part  of  a module  D,  it  does  not  mean  that  units  containing  a use  clause 
use  D: 

will  also  see  M.  When  this  kind  of  transitivity  is  desired  it  can  be  achieved  explicitly  by  declara- 
tions, in  particular  by  renaming  declarations. 

Consider  for  example 

package  M is 

type  T is  private, 
procedure  P(X  : T); 

E : exception: 
end  M; 

Suppose  now  that  a package  D defines  additional  operations  for  the  type  T in  terms  of  the  opera- 
tions supplied  by  M,  and  suppose  we  want  to  make  T,  P,  and  E available  to  all  users  of  the  package 
D without  an  explicit  use  M clause.  This  can  be  achieved  as  follows: 
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package  0 is 

subtypo  T is  M.T; 
procedure  P ronamos  M P 

-•  additional  operations  defined  by  0 

E exception  renames  M E; 
end  0 

Note  that  we  could  also  have  declared  the  type  T by  a derived  type  definition 

type  T is  new  M.T; 

This  latter  form  could  be  used  if  we  wanted  to  forbid  the  use  of  operations  defined  by  another 
package  for  objects  of  type  M.T  at  the  same  time  as  those  defined  by  the  package  D 


8.3.5  Access  to  the  Properties  of  Types  Defined  Within  Modules 


It  is  important  to  define  which  of  the  properties  of  a type  declared  in  the  visible  part  of  a module 
are  accessible  outside  the  module  (for  example  within  another  unit  mentioning  the  module  in  its 
use  clause)7  The  answer  to  this  question  is  simple:  the  only  available  properties  are  those  declared 
in  the  visible  part. 

As  a first  case  consider  a type  declaration  of  the  usual  form,  say  a record  type  declaration.  If  such 
a declaration  appears  in  the  visible  part  of  a module,  this  type  is  available  without  restrictions  to 
outside  units  In  particular  these  can  declare  variables  and  carry  out  operations  (such  as  compo- 
nent selection,  etc.)  in  ‘ ill  knowledge  of  the  data  structure  specified  by  the  type. 

For  a type  declared  as  private  on  the  other  hand  the  visible  part  gives  only  the  type  name  and  the 
specification  of  the  subprograms  applicable  to  objects  of  this  type  These  subprograms  are  said  to 
be  attributes  of  this  type  They  are  the  only  operations  applicable  to  objects  of  the  type  apart  from 
assignment  and  comparison  for  equality  or  inequality  (unless  the  private  type  is  restricted) 

The  separation  of  inheritance  properties  by  these  rules  is  elementary  and  its  logical  basis  is  clear. 
More  complicated  rules  have  been  investigated,  but  all  involve  elaborations  of  the  language  in  an 
area  which  is  a subject  of  current  research 

Since  these  attributes  are  the  only  properties  of  a private  type  that  are  accessible  outside  the 
module  they  are  also  the  only  properties  that  can  be  inherited  in  a derived  type  definition.  As  an 
example,  consider  the  following  declaration  of  the  type  MY_F!LE: 

declare 

use  SIMPlE_IIMPUT_OUTPUT, 
type  MY_FILE  is  new  FILE.NAME; 

begin 

end 

Within  the  block,  the  only  operations  available  on  objects  of  type  MY_F!LE  are  assignment,  com- 
parison the  function  CREATE,  and  the  procedures  READ  and  WRITE. 


Conceptually  we  may  view  predefined  types  such  as  INTEGER  and  FLOAT  as  being  types  thus 
declared  in  predefined  packages,  along  with  their  attributes.  Inheritance  of  their  properties  in 
declarations  such  as 

type  MY  REAL  l«  new  FLOAT. 

is  hence  only  the  result  of  the  application  of  the  general  rule. 

Within  a module  body  the  characteristics  of  a private  type  are  known  as  it  the  type  were  not 
private  For  example  if  the  type  is  a record  type  its  components  can  be  denoted  with  the  usual  syn 
tax  of  selected  components.  Some  precautions  must  be  taken  when  one  of  the  visible  attributes  of 
the  type  Is  defined  in  terms  of  an  existing  attribute  with  the  same  name  As  an  example  consider 
the  skeleton  of  the  package  KEY  MANAGER  given  in  the  Reference  Manual  (section  7.4): 

package  KEY  MANAGER  is 
'ype  KEY  is  private 

function  \‘|X,Y  KEY)  return  BOOLEAN; 
private 

type  KEY  Is  new  INTEGER  range  0 INTEGER  LAST, 

and 

package  body  KEY  MANAGER  is 

function  “<-(X,Y  : KEY)  return  BOOLEAN  Is 
begin 

return  INTEGER(X)  v.  INTEGER(Y); 

end 

end  KEY  MANAGER. 

Within  the  package  body  the  definition  of  the  derived  type  KEY  is  known.  The  operation 
declared  in  the  visible  part  is  a (perfectly  legal)  redeclaration  of  the  operation  inherited  from 
the  type  INTEGER  Thus,  with  the  declarations 

U.  V KEY; 

within  the  body  of  the  package,  the  relation 
U V 

refers  to  the  operation  ' Inherited  from  integer,  whereas  the  relation 

U v V 

refers  to  the  operation  V defined  within  the  module  itself  (in  this  case,  of  course,  it  does  not  mat 
ter  since  this  redefinition  is  equivalent  to  the  inherited  operation).  It  should  be  noted  that  within 
the  body  of  the  function  "v"  itself,  the  relation 

X Y 

would  he  a recursive  call  of  the  function  In  order  to  obtain  the  operation  defined  on  Integers,  a 
qualification  must  be  used.  For  axiimplo 

INTEGERIX)  v INTEGER(Y) 

invokes  the  operation  <.  defined  on  integers 
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8.3.6  Instantiation  and  Initialization  of  Objacts  of  Privata  Typas 


The  elaboration  of  an  object  declaration  results  in  8 static  reservation  of  space  for  the  cor- 
responding object,  whether  the  type  of  the  object  is  private  or  not. 

The  initialization  of  an  object  of  a private  type  may  be  achieved  by  assigning  a private  constant  or  a 
function  returning  a result  of  the  type.  However,  there  are  cases  where  we  want  the  representation 
of  an  object  of  a private  type  to  satisfy  some  invariant  as  soon  as  the  object  is  created,  although  a 
complete  initialization  would  be  redundant.  This  is  achieved  by  means  of  initialization  of  record 
components.  Consider  the  following  package  declaration: 

package  ALl_ABOUT_STACKS  is 
restricted  type  STACK  is  private: 

procedure  PUSH  (E  : in  ELEMENT;  S : in  out  STACK): 

procedure  POP  (E  : out  ELEMENT;  S in  out  STACK); 

private 

type  STACK  is 
record 

TOP  : INTEGER  range  0 1000  :=  0; 

SPACE  : array!  1 . 1000)  of  ELEMENT; 

end  record; 

end; 

For  any  declaration  of  an  object  of  type  STACK,  the  component  TOP  is  initialized  to  zero.  Thus,  the 
stack  invariants  are  satisfied  as  soon  as  a stack  is  elaborated  (another  example  was  shown  in  sec- 
tion 8.2.3  above,  with  the  initialization  of  file  names  in  the  package  SAFEJO). 

This  initialization  capability  is  clearly  limited,  but  should  be  sufficient  in  most  cases.  When  more 
complicated  forms  of  initialization  are  needed,  the  visible  part  of  the  module  must  provide  the 
specification  of  an  appropriate  procedure  performing  the  initialization.  This  procedure  must  then  be 
called  by  the  programmer  whenever  declaring  a variable  ol  the  private  type,  prior  to  any  other 
operation. 


8.4  Conclusion  and  Summary 


Modularity  seems  to  have  emerged  as  one  of  the  overriding  concerns  in  contemporary  programm 
ing  Unfortunately,  this  one  simple  word  encompasses  a number  of  desirable  but  not  necessarily 
compatible  objectives,  which  gives  rise  to  as  many  different  interpretations  as  there  are  priorities 
among  the  various  objectives  It  comes  as  no  surprise,  therefore  to  find  that  there  exists  no  real 
consensus  as  to  how  this  elusive  quality  is  to  be  achieved  in  practice  let  alone  about  how  to 
provide  appropriate  support  for  modularization  within  a high  order  programming  language. 

Curiously  enough  in  such  a situation,  the  Steelman  requirements  are  quite  specific  as  to  the  kinds 
of  facilities  that  shall  be  provided  for  this  purpose.  Since  we  strongly  concur  with  the  requirements 
as  stated,  many  alternatives  that  have  been  proposed  elsewhere  have  not  been  discussed  in  this 
chapter.  For  a more  extensive  examination  of  the  different  linguistic  approaches,  the  reader  is 
referred  to  jGK  1977|. 
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A straightforward  approach  was  taken  for  the  module  facility  in  the  Green  language  Modules 
provide  an  ability  to  package  information.  When  defining  a module,  the  programmer  simply  states 
the  visible  information  and  provides  the  module  implementation  as  a separate  text  (its  body). 
Access  to  information  of  a module  body  is  not  (directly)  possible  outside  the  module  body.  Thus, 
modules  support  information  hiding  as  well  as  control  of  visibility. 

The  module  facility  is  central  to  the  definition  of  encapsulated  data  types;  it  provides  complete 
control  over  the  available  operations  for  such  types.  Finally,  modules  can  be  parameterize..'  by 
generic  clauses,  separately  compiled,  and  entered  in  libraries. 

All  of  these  aspects  are  in  many  respects  fundamental  for  program  development.  Modules  are 
expected  to  be  used  to  construct  libraries  containing  common  pools  of  data  and  types,  application 
packages,  and  complete  systems. 
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9.  General  Program  Structure  and  Visibility 


1 


( 


9.1  Introduction 


Central  to  the  definition  of  the  Green  language  has  been  a combined  study  of  the  general  program 
structure,  of  the  rules  defining  the  visibility  of  identifiers  at  various  points  of  a program,  and  of  the 
facilities  offered  for  separate  compilation. 

A major  goal  in  this  design  was  to  give  the  programmer  precise  control  over  his  name  space  : tl  e 
set  of  names  that  he  may  define  and  use.  It  is  important  to  be  able  to  introduce  new  names 
without  having  to  bother  about  possible  conflict  with  preexisting  names.  This  requires  an  ability  to 
control  the  inheritance  of  names  from  other  contexts.  As  mentioned  in  a previous  chapter,  the 
notion  of  module  is  essential  to  achieve  this  kind  of  control. 

Another  goal  was  to  provide  the  same  visibility  rules  for  all  program  units  (subprograms,  modules 
and  blocks)  whether  they  are  separately  compiled  or  not. 

The  subjects  of  general  program  structure  and  of  visibility  rules  are  connected  in  many  ways,  in 
particular  because  of  the  possibility  of  nesting  program  units.  Both  subjects  are  also  related  to  the 
issue  of  separate  compilation.  This  chapter  will  discuss  program  structure  and  visibility  in  that 
order.  The  subject  of  separate  compilation  is  treated  in  the  next  chapter. 


9.2  Program  Structure 


The  overall  structure  of  a Green  program  text  (that  is,  a compilation  unit)  is  similar  to  that  of  an 
Algol  60  or  Pascal  text.  It  appears  as  a nested  structure  of  program  units,  that  are  subprograms, 
modulus,  and  blocks. 

Nesting  <s  achieved  through  declarative  parts.  A declarative  part  may  contain  subprogram  and 
module  bodies.  These  may  in  turn  contain  a declarative  part.  Nesting  is  also  achieved  by  blocks  in 
sequences  of  statements. 

A key  question  in  the  definition  of  the  general  program  structure  is  that  of  the  purpose  of  nesting. 
Clearly,  nesting  has  been  used  in  Algol  60  and  Pascal  in  relation  to  scope.  In  such  languages,  two 
units  are  written  in  the  context  of  the  same  declarative  part  if  they  are  to  share  the  visibility  of 
some  common  outer  objects. 

Is  this,  however,  the  only  purpose  of  nesting?  If  it  were,  a logical  conclusion  would  be  the 
systematic  unnesting  of  units  that  do  not  share  any  common  visibility. 
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We  consider  this  view  to  be  too  extreme.  Units  that  do  not  have  any  visibility  dependence  may 
nevertheless  be  maintained  together  in  a nested  text  structure  for  benefit  of  the  logical  exposition 
of  the  program.  An  analogy  may  be  made  with  an  encyclopedia,  where  the  materials  are  organized 
into  subjects  and  sub-subjects.  It  is  the  knowledge  of  this  organization  that  permits  an  easy 
retrieval  of  a given  subject. 

Systematic  unnesting  of  units  that  do  not  share  any  common  visibility  would  produce  a sequence 
of  small  units  not  unlike  a sequence  of  Fortran  subprograms.  Finding  a given  unit  in  such  a 
sequence  is  difficult  unless  aided  by  a dictionary.  Reading  the  program  may  also  be  difficult  since 
the  structure  of  the  text  does  not  reflect  the  logical  organization  and  the  logical  connections. 

For  these  reasons,  the  possibility  of  nesting  units  has  been  retained.  Moreover,  provisions  have 
been  made  to  control,  and  possibly  to  restrict,  the  visibility  of  nested  units. 

In  a declarative  part  we  may  thus  have  a sequence  of  declarations  followed  by  a sequence  of 
bodies  of  nested  program  units.  In  particular,  the  sequence  of  declarations  may  include  the 
specification  of  nested  subprograms  and  modules.  In  general  it  is  possible  to  provide  the  definition 
of  subprograms  and  modules  in  two  textually  distinct  parts: 

(a)  the  specification,  which  indicates  the  logical  interface  (between  definition  and  use)  of  the  unit 
at  hand 

(b)  the  body,  which  describes  the  particular  realization  for  the  specification. 

This  possibility  has  far  reaching  implications,  in  that  it  provides  a single  basis  for  achieving  several 
different  objectives,  notably  textual  clarity,  abstraction,  and  separate  compilation.  We  first 
illustrate  this  ability  in  the  case  of  a procedure.  For  instance,  one  might  write  the  specification 

procedure  PUSH  (E  : in  ELEMENT;  S : in  out  STACK); 

This  specification  contains  the  name  of  the  procedure  and  the  specification  of  the  mode  and  type 
of  its  formal  parameters.  Such  a declaration  is  sufficient  to  specify  the  interface  of  PUSH,  both 
syntactically  and  semantically,  at  least  with  regard  to  type  checking.  From  this  point  of  view  the 
specification  conveys  all  one  needs  to  know  in  order  to  make  use  of  (i.e  call)  the  procedure  PUSH. 
The  specification  could  be  augmented  by  comments  specifying  pre-conditions  and  post-conditions 
end  any  exceptions  possibly  raised  by  PUSH. 

Obviously  however,  this  formulation  of  PUSH  is  incomplete  in  that  it  does  not  define  an  actual 
implementation  of  the  procedure.  The  latter  is  provided  as  a procedure  body: 

procedure  PUSH  (E  : in  ELEMENT;  S : in  out  STACK)  la 

begin 

if  S. INDEX  = S.SIZE  then 
raise  STACK_OVERFLOW; 

else 

S. INDEX  S. INDEX  + 1; 

S. SPACE  (S. INDEX)  :=  E; 

end  W; 
end  PUSH; 

These  two  constructs,  the  declaration  and  the  body,  jointly  form  the  definition  of  the  procedure. 
For  reasons  of  syntactic  convenience  the  procedure  declaration  may  be  omitted  if  the  body 
appears  in  the  same  declarative  part.  For  reasons  of  readability  the  specification  is  repeated  in  the 
body. 
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A similar  partition  is  provided  for  modules.  A module  specification  provides  the  interface  to  the 
user,  that  is,  it  indicates  whether  the  module  is  a package  or  a task  and  states  the  properties  of  its 
visible  part.  For  example  the  specification  of  a SIMPLE_INPUT_OUTPUT  package  is  provided  as 
follows: 

package  SIMPLE_INPUT_OUTPUT  is 

restricted  type  FILE_NAME  is  private; 

procedure  CREATE  (FILE  : out  FILE_NAME); 

procedure  READ  (ELEM  . out  INTEGER:  F : in  FILE.NAME); 

procedure  WRITE  (ELEM  : in  INTEGER;  F : in  FILE_NAME>; 

private 

type  FILE_NAME  is  new  INTEGER  range  0 ..  50; 
end  SIMPLE_INPUT_OUTPUT; 

In  this  example,  the  specification  of  SIMPLE_INPUT_OUTPUT  provides  the  user  with  the 
specification  of  the  name  of  the  type  FILE_NAME  and  also  with  the  specification  of  the  associated 
procedures  CREATE,  READ  and  WRITE.  This  constitutes  the  logical  interface  of  the  package. 

The  module  implementation  is  always  provided  as  a textually  distinct  module  body  as  shown  in  the 
sketch  below; 

package  body  S(MPLE_INPUT_OUTPUT  is 

type  FILE_DESCRIPTOR  is 

record 

--  components  of  each  file  descriptor 

end  record. 

DIRECTORY  : array  (FILE_NAME)  of  FILE_DESCRIPTOR; 

--  other  local  constants,  variables  and  subprograms 

procedure  CREATE  (FILE  : out  FILE_NAMEj  is  ...  end  CREATE; 

procedure  READ  (ELEM  : out  INTEGER;  F : in  FILE.NAME)  is  ...  end  READ; 

procedure  WRITE  (ELEM  : in  INTEGER;  F . in  FILE_NAME)  is  ...  end  WRITE- 

end  SIMPLE_INPUT_OUTPUT; 

As  in  the  case  of  procedures,  the  module  specification  and  the  module  body  jointly  define  the 
module  in  question.  For  pragmatic  reasons  (a  module  specification  is  generally  much  larger  than  a 
procedure  specification),  the  module  body  does  not  repeat  the  information  contained  in  the 
module  specification. 
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9.3  Scope  and  Visibility  Rules 


r 


The  visibility  rules  provided  in  the  Green  language  combine  classical  inheritance  rules  with  the 
ability  to  control  explicitly  the  set  of  names  that  can  be  accessed  within  a given  program  context. 
This  ability  follows  from  the  naming  conventions,  the  facilities  offered  by  modules  and  the  visibility 
restrictions.  A renaming  capability  is  also  provided. 

We  first  discuss  the  basic  scope  model,  then  the  naming  conventions,  use  clauses,  visibility  restric- 
tions, and  renaming.  Finally  we  discuss  the  rule  of  linear  elaboration  of  declarations  which  has 
been  adopted  for  reasons  of  readability. 


9.3.1  Basic  Scope  Model 


l 


The  search  for  simple  and  uniform  scope  rules  has  led  to  the  adoption  of  an  almost  traditional 
appioach:  within  a program  unit,  identifiers  declared  in  outer  contexts  are  automatically  visible  in 
inner  nested  contexts  unless  an  explicit  visibility  restriction  is  given. 

The  word  context,  as  used  here,  generally  corresponds  to  a subprogram  or  block  containing  a 
declarative  part,  or  to  a record  type  definition.  hus  the  basic  rule  is  essentially  that  of  Algol  60. 
The  only  departure  is  that  the  convention  is  applicable  within  a restricted  program  unit  rather  than 
throughout  an  entire  program. 

The  fundamental  reason  for  selecting  this  liberal  approach  is  the  pragmatic  assumption  that  names 
declared  together  are  normally  meant  to  be  used  together.  Consider,  for  instance,  the  skeleton 

procedure  P is 

type  T is  ...;  — type  declaration 

V : T;  — variable  declaration 

procedure  Q;  — procedure  declaration 


procedure  Q is 

begin 

end  Q; 
begin 

end  P: 

Presumably  the  names  T,  V and  Q are  defined  in  the  same  context  (the  declarative  part  of  P) 
because  they  are  intended  to  be  used  together,  here  in  the  sequence  of  statements  of  P.  Extending 
this  reasoning  to  inner  contexts  means,  for  instance,  that  the  names  T.  V,  and  possibly  Q are  also 
visible  within  the  body  of  Q,  so  that  the  body  may  be  directly  defined  in  terms  of  these  names.  This 
suggests  the  assumption  that  entities  declared  in  the  same  context  have  mutually  dependent 
definitions,  unless  explicitly  stated  otherwise. 
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ZZ  111 T. ►!  considered  was  to  designate  certain  syntactic  categories  such  as  procedures  and 
modules  as  being  alwnvs  closed,  and  then  to  require  some  form  of  explicit  import  directive  in  order 
to  make  externally  declared  names  visible  within  such  contexts.  This  was  ultimately  deemed  unac- 
ceptable because  it  would  leao  to  clutter  and  to  long  name  lists  in  many  common  cases 

The  following  example  illustrates  the  unnecessary  redundancy  of  the  directive  ^ees  T.  C.  L\  where 
the  procedures  P_1  through  P_N  are  obviously  mean,  to  work  with  T,  C and  L. 

— the  following  is  not  a Green  text 


package  D is 
type  T is  ...; 

C : constant  T :=  ...; 


procedure  P_1  (...); 
procedure  P_2  (...); 

procedure  P_N(...I: 
end  0; 

package  body  D is 

t : T; 


--  note:  “sees  T.  C,  L"  is  not  legal  in 

procedure  P_1(...)  sees  T,  C.  L is 

procedure  P_2(...)  sees  T,  C,  L is 

procedure  P_N(.  > sees  T,  C.  L is 

end  D; 


Green 

end  P_1 ; 
end  P_2: 

end  P_N: 


Early  experience  with  the  Euclid  language,  where  such  an  approach  was  taken,  has  shown  that  the 
danger  of  long  name  lists  is  not  to  be  underestimated.  Because  of  transitivity.  Euclid  import  lists 
can  get  very  long.  The  danger  is  then  that  programmers  may  tend  to  use  standard  import  lists  in 
fear  of  omitting  something  (as  is  often  done  for  Fortran  common  lists).  In  any  case,  long  name  lists 
are  usuaHy  skipped  when  reading  and  this  defeats  their  very  purpose.  The  classical  argument 
developed  by  Dijkstra  (D.  72|.  about  our  inability  to  deal  with  a large  number  of  entities  at  the 
same  time,  also  applies  to  long,  and  therefore  unstructured  name  lists. 


The  only  way  to  avoid  this  form  of  text  clutter  is  to  make  automatic  inheritance  the  default  rule 
The  argument  ,s  that  the  textual  embedding  of  declarations  is  already  a strong  indication  of  poten- 
tial dependencies.  The  systematic  inclusion  of  additional  import  directives  does  not  usually 
provide  much  information  that  may  usefully  be  exploited  by  the  translator  and  it  is  likely  to  distract 
the  readers  (and  writers)  of  programs. 


More  significantly,  we  came  to  the  conclusion  that  whether  a given  syntactic  category  should  be 
an  open  scope  or  a restricted  (closed)  scone  is  a highly  subjective  question.  The  answer  may  vary 
from  one  usage  to  another,  depending  on  the  si/e  of  a particular  program  unit,  the  depth  to  which 
it  is  nested,  the  probability  of  subsequent  recompilation,  and  so  on. 
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It  seems  clear,  therefore,  that  the  syntax  of  the  language  should  not  arbitrarily  impose  a decision  in 
this  regard.  For  this  reason  we  have  adopted  the  following  approach: 

• all  syntactic  constructs  that  introduce  declarations  normally  inherit  the  identifiers  of  outer 
contexts. 

• Specific  subprograms  and  modules  may  optionally  be  specified  as  being  restricted  program 
units,  i.e.  units  with  a restricted  visibility  of  outer  contexts. 


9.3.2  Naming  conventions 


Since  classical  inheritance  of  identifiers  from  outer  contexts  is  the  default  rule,  redeclaration  of 
identifiers  is  possible,  with  the  effect  of  hiding  the  outer  definitions  within  the  inner  context. 

Some  of  the  difficulties  existing  in  identifier  redeclarations  disappear  if  the  names  of  the  cor- 
responding entities  can  be  written  as  selected  components,  i.e.  using  the  dot  notation.  Consider, 
for  example,  a type  T declared  in  a procedure  P,  and  assume  the  identifier  T redeclared  in  an  inner 
context.  The  type  name  can  still  be  written  as  P.T  in  the  inner  context  (exploiting  the  fact  that  the 
identifier  P is  visible  there)  and  may  thus  be  used  in  qualified  expressions  and  so  forth,  if  the  need 
arises. 

Naming  by  selected  components  is  also  the  general  rule  used  for  denoting  identifiers  declared  in 
packages  and  tasks  outside  of  their  own  specification  and  body.  Thus  an  identifier  I declared  in  the 
visible  part  of  a module  D is  denoted  by  the  selected  component  D.l  outside  the  module,  in  spite  of 
the  fact  that  I is  not  directly  visible  there. 

As  an  additional  syntactic  convenience  a use  clause,  mentioning  names  of  modules,  may  appear  at 
the  start  of  a declarative  part.  In  the  absence  of  any  conflicting  identifier,  its  effect  is  to  permit 
designation  of  an  identifier  of  the  visible  part  directly,  as  if  the  identifier  were  declared  at  the  place 
of  the  module  specification  containing  it.  For  example,  in  a context  including  the  use  clause 

um  0,  E; 

the  identifier  I is  an  acceptable  abbreviation  for  D.l  provided  that  it  is  declared  in  D and  is  not  hid- 
den by  an  intervening  redeclaration  of  I,  and  provided  also  that  the  module  E does  not  contain  an 
identifier  I in  its  visible  part.  In  all  cases  of  conflict,  the  name  must  be  given  in  full  as  a selected 
component. 

These  rules  are  illustrated  by  the  following  example: 
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package  D i* 


T.  U.  V : BOOLEAN: 

end  D: 

procedure  P is 

package  E is 

8,  W.  V : INTEGER: 

and  E; 

procedure  Q is 

T.X  : REAL: 

begin 

declare 


uaa  0.  E; 

begin 

— the  name 

T 

means  Q.T,  not  D.T 

--  the  name 

U 

means  D.U 

— the  name 

B 

means  E.B 

— the  name 

W 

means  E.W 

— the  name 

X 

means  Q.X 

--  the  name 

V 

is  illegal  : it  must  be  written  either  D.V  or  E.V 

and  Q : 
begin 

and  P; 

In  deciding  which  names  are  visible  within  the  sequence  of  statements  of  the  block  we  apply  the 
following  rule: 

(a)  First  we  inherit  the  names  declared  in  outer  contexts  and  not  redefined.  Thus  we  inherit  the 
names  D and  P.  the  names  E and  Q introduced  within  P,  and  the  names  T and  X introduced 
within  Q. 

(b)  Then  we  consider  'he  names  that  may  additionally  be  introduced  by  use  clauses.  In  the  above 
example  we  only  hove  to  consider  the  names  that  are  in  the  visible  parts  of  D and  E.  We  retain 
names  that  appear  in  only  one  of  these  modules  and  that  do  not  conflict  with  a name 
introduced  in  the  step  (a).  Hence  the  names  additionally  introduced  are  U,  B,  W.  Nested  use 
clauses  would  be  treated  in  the  same  way. 

A consequence  of  this  rule  is  that  a name  which  is  made  directly  accessible  by  a use  clause  cannot 
hide  another  name.  This  .is  quite  essential  for  maintainability  reasons:  assume  for  example  that 
the  specification  of  the  package  D is  modified  to  include  the  declaration  of  some  new  entity  called 
X.  This  should  normally  have  no  effect  on  the  procedure  Q.  In  particular  the  inner  reference  to  X 
should  retain  its  meaning  and  should  hence  mean  Q.X  before  and  after  the  modification.  (Note  that 
we  have  only  reduced  the  magnitude  of  this  general  problem  since  a later  introduction  of  W within 
D would  conflict:  we  believe  the  complete  solution  to  be  in  maintenance  tools.) 
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A similar  maintainability  argument  leads  us  to  reject  a unique  visibility  rule,  i.e.  a rule  forbidding 
redeclarations  of  already  visible  identifiers.  If  redefinitions  of  identifiers  were  not  allowed,  the  later 
introduction  of  some  entity  named  X in  the  declaration  list  of  P would  force  textual  modification  of 
a procedure  like  Q,  which  should  normally  be  unaffected  by  this  change. 

Note  that  use  clauses  may  be  viewed  as  a form  of  the  import  directives  mentioned  in  section  9.3.1 . 

However  the  items  listed  in  use  clauses  can  only  be  names  of  modules  and  the  risk  of  long  use 
lists  is  correspondingly  reduced.  Naturally,  effective  modularization  will  depend  upon  the  user 
writing  modules  in  such  a way  that  related  definitions  are  in  the  same  module;  related  definitions 
will  usually  be  required  together. 


9.3.3  Restricted  Program  Units 


Whereas  we  subscribe  to  the  classical  rule  of  inheritance  as  a default  rule,  it  is  nevertheless  impor- 
tant to  provide  means  for  controlling  this  inheritance. 

We  have  already  shown  in  the  chapter  on  modules  that  *hey  can  be  used  as  a powerful  structuring 
tool  for  scope  control.  The  basic  ability  provided  by  modules  is  the  identification  of  a visible  part, 
well  isolated  from  the  hidden  information  contained  if  the  module  body  and  possibly  also  in  the 
private  declarative  part.  Used  in  conjunction  with  the  naming  convention,  modules  may  thus  be 
used  to  discipline  the  use  of  names  and  to  avoid  saturation  of  the  name  space. 

An  additional  capability  is  provided  in  order  to  control  explicitly  the  inheritance  of  names  defined  in 
outer  units.  This  capability  is  called  a visibility  restriction  and  the  subprograms  and  modules  which 
have  such  a restriction  are  said  to  be  restricted  program  units. 

The  main  purpose  of  a visibility  restriction  is  to  limit  the  intrusion  of  names  pervading  from  outer 
units.  This  will  be  achieved  by  stating  explicitly  what  environment  should  be  inherited.  In  general 
a visibility  restriction  has  the  form 


restricted  l(unit_name  |,unit_name|)j 

where  the  first  name  may  be  the  name  of  an  enclosing  program  unit  but  otherwise  the  names  are 
names  of  modules. 

The  usual  reasons  for  avoiding  long  name  lists  apply  to  visibility  restrictions  as  well.  For  this 
reason  the  names  that  may  appear  in  visibility  restrictions  are  those  of  program  units  rather  than 
those  of  individual  variables.  Precise  control  of  inheritance  should  be  obtained  by  grouping  the 
elements  that  are  likely  to  be  imported  together  into  a single  module. 

The  following  example  containing  the  procedures  P,  Q,  R and  the  modules  D,  E,  F is  used  to 
illustrate  the  possible  cases.  In  addition  L is  assumed  to  be  the  name  of  a library  module. 


I 
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package  0 is 

T.  U.  V : BOOLEAN; 
and  0; 

procedure  P is 
use  0; 

— local  declarations  of  P 

package  E is 

B.  W.  V ; INTEGER; 
and  E; 

procedure  Q is 
use  E; 

— local  declarations  of  Q 

package  F is 

end  F; 

procedure  R is 

end  R; 
end  Q; 
end  P; 

Consider  now  the  various  forms  of  visibility  restrictions  that  can  prefix  the  procedure  R.  The 
simplest,  and  most  radical,  restriction  is  as  follows: 

restricted  procedure  R is 


In  this  form.  R inherits  no  names  from  outer  units  apart  from  the  predefined  identifiers.  In  par- 
ticular the  names  of  the  packages  D,  E,  F are  not  inherited  and  the  use  clauses  given  for  D and  E in 
outer  units  are  inoperative  within  R. 

The  effect  of  the  visibility  restriction  is  thus  to  restart  with  a completely  fresh  name  space  in  condi- 
tions similar  to  those  of  the  main  program.  As  a next  step  consider 

restricted  (0.  F.  L) 
procedure  R is 

and  R; 

This  time  the  restriction  includes  a visibility  list  mentioning  the  names  of  modules,  none  of  which  is 
enclosing  R itself.  The  effect  of  the  restriction  is  as  before  to  start  with  a fresh  name  space  apart 
from  the  listed  names  D,  F,  L.  As  before,  any  use  clause  given  outside  R is  inoperative  within  R. 
The  appearance  of  the  module  names  D F L in  the  visibility  list  means  that  these  names  can 
appear  within  R in  use  clauses  and  can  serve  to  form  selected  components  such  as  D.T. 

Consider  finally  the  case  where  the  first  name  mentioned  in  the  visibility  restriction  is  that  of  a unit 
textually  enclosing  R 


restricted  (Q.  D.  L) 
procedure  R ie 

end  R; 

r The  mention  of  the  enclosing  program  unit  Q in  the  visibility  list  means  that  R does  not  see  any 

name,  apart  from  the  module  names  D and  L,  beyond  the  names  declared  in  Q itself.  Hence  the 
only  names  inherited  by  R are  Q,  F,  those  introduced  by  the  local  declarations  of  Q,  and  the  names 
D and  L As  before,  any  use  clause  given  outside  R is  inoperative  within  R,  in  particular  that  of  E. 

As  a final  example  consider  the  following  procedure: 

procedure  P (X  : INTEGER)  is 

LP  : BOOLEAN; 

package  E is 

LE  ; BOOLEAN; 

... 

end  E; 

package  body  E is 

LBE  : BOOLEAN; 

end  E; 

procedure  Q (Y  : INTEGER)  is 
LQ  : BOOLEAN; 


restricted  (Q,  E) 

procedure  R (Z  : INTEGER)  is 

begin 

--  The  local  identifiers  of  Q are  visible: 

~ the  procedure  Q itself 

--  the  parameter  Y 

--  the  local  variable  LQ 

— the  procedure  R itself 

— the  parameter  Z of  R 

--  The  package  name  E is  visible: 

~ names  such  as  E.LE  can  be  used 
--  the  clause  "use  E;'  is  legal 

— as  usual,  LBE  is  not  visible 

--  The  names  P,  X,  and  LP  are  not  visible 

end  R; 

begin 


end  Q; 


end  P; 
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9.3.4  Summary  of  tha  visibility  rulas 


In  order  to  define  the  set  of  identifiers  that  are  visible  at  a given  program  point  we  have  to  con- 
sider: 

(a)  The  set  E of  identifiers  inherited  from  enclosing  units:  The  units  to  be  considered  are  all  units 
enclosing  the  point  considered,  up  to  the  immediately  enclosing  restricted  unit  or  the  compila- 
tion unit  itself.  The  set  E can  be  built  layer  by  layer  starting  from  the  latter  unit.  It  is  initialized 
with  the  predefined  identifiers.  Each  layer  adds  to  E the  identifiers  that  it  declares.  If  an  iden- 
tifier added  by  the  layer  considered  is  already  in  E,  the  new  meaning  is  retained. 

(b)  The  list  M of  modules  found  so  far  in  use  clauses: 

This  list  is  the  union  of  the  modules  found  in  the  use  clauses  of  the  enclosing  units  up  to  the 
immediately  enclosing  restricted  unit  or  the  compilation  unit  itself. 

The  set  of  identifiers  that  are  visible  at  a given  program  point  contains  the  set  E and  the  identifiers 
satisfying  the  two  following  conditions: 

(1)  They  are  declared  in  one  and  only  one  of  the  modules  of  M 

(2)  They  are  not  already  in  E 

The  latter  condition  means  that  an  identifier  made  directly  visible  by  a use  clause  cannot  hide  any 
other  identifier. 


9.3.5  Scope  rules  for  enumeration  and  record  types 


Character  types  are  handled  as  enumeration  types  and  there  may  be  several  character  types 
defined  within  a program.  Ai  a ddrisdtiu'irh'eli,  a character1  literal  such  as  "A"  may  belong  to  several 
enumeration  types.  For  uniformity,  the  same  identifier  may  also  appear  in  several  enumeration 
types. 

typs  COLOR  is  (WHITE,  RED,  YELLOW,  GREEN,  BLUE,  BROWN); 
type  LIGHT  is  (RED.  AMBER,  GJjtEEN); 

Here  references  to  the  literals  RED  and  GREEN  require  a qualified  expression  such  as  LIGHT 
(GREEN)  when  the  context  is  insufficient  to  determine  the  type. 

An  essential  requirement  of  the  scope  is  that  it  must  not  be  possible  to  declare  a variable  with  the 
name  of  any  enumeration  value.  If  this  were  allowed,  the  declaration 

BROWN  : COLOR; 

would  give  rise  to  ambiguities.  For  instance  when  comparing  another  variable  to  BROWN  it  would 
not  be  possible  to  know  whether  the  literal  or  the  variable  were  meant. 


IF.  %'  RttW  hand  IhfF  tedeclgretjpn  of  ap  enumergfipq  typp  is  np  ppppierp-  If  foe  tyRe 
| |S  flftplerefj  in  | prRPBffHrs  p end  then  reppclared  jn  t}R  inn^p  pn'T  names  in  the  fprpi  pf 
^PlPpfPd  PRmpflPP'm  Ifpr  example  P CQppR)  can  Re  uspd  fo  refer  tp  the  quter  definition 

^ FPPRrd  fYPS  FPFnifjpn  jntfpflpcg?  a new  scppe.  Hpncp  cpmpoppqt  identifiers  may  be  freely 
F«P-  TFP  fepprd  ?pppe  is  opened  for  eaph  selection  by  tfoi  dpi  fp||qy*jng  the  neme  of  a iocord 
yanaple  in  the  selected  rpmpqnent. 

Eppmetetion  literals  yyitpin  a record  are  not  just  within  the  scope  of  the  recqrd  bp1  within  the 
scope  pf  the  inpermqst  enclosing  hlpck,  subprogram  or  rpodble  Hence  wifh 

FiPf  FS8!Fdf^|-  »l 

ng^lT  : (PRINTER.  HEADER.  piS*.  PRMWI: 

eflff  reporfl 


READER  : INTEGER; 


illegal  declaration 


the  depletion  of  the  yariable  RE^pER  is  invalid  since  it  clashes  wjth  tfip  declgratiqn  of  the 
eppmeration  valpe  READER  within  the  record.  However,  the  dPflaration  UNIT  : iNtEGEft;  would 
bp  valid  (bpt  no  dpubt  misleading). 

As  with  Pascal,  variants  within  a record  do  not  introduce  a new  scope.  Hence  the  component 
names  of  pvery  variant  must  be  distinct,  qven  if  they  are  semqntically  equivalent  as  far  as  the 
PFPgmmrner  is  concerned.  The  reason  for  not  introducing  a new  scqpe  with  a variant  can  be  seen 
from  the  following  example: 

T ]• 

record 

DISCRIMINANT  : constant  BOOLEAN; 

DISCRIMINANT  of 
whan  TRUE  =>  A : REAL; 

whan  FALSE  =>  A : INTEGER;  — illegal  declaration  of  A 


and  record; 

R : T: 

A selected  component  such  as  R.A  would  have  to  be  treated  as  a conditional  expression  possibly 
delivering  results  of  alternative  types. 


9.3.6  Renaming 


I 


A renaming  capability  is  offered  in  the  Green  language.  As  an  example  consider 

declare 

L : PERSON  rename*  LEFTMOST.PERSON; 

R : PERSON  renames  TO_BE_PROCESSED(NEXT); 

begin 

L.AGE  :=  L.AGE  + 1; 

R AGE  :=  RAGE  - 1; 

W L.BIRTH  < R. BIRTH  then 
L.RANK  :=  L.RANK  + 1; 

else 

R.RANK  :=  R.RANK  + 1; 
end  If; 
end. 

The  renaming  declarations  of  L and  R are  used  to  introduce  new  local  names  for  the  outer 
variables  LEFTMOST_PERSON  and  TO_BE_PROCESSED(NEXT).  In  the  sequence  of  statements 
of  the  block,  L and  R may  be  used  as  convenient  names  of  the  variables  that  they  represent.  In  this 
sense,  the  renaming  facility  can  be  used  for  purposes  similar  to  the  Pascal  with  statement  as  a 
convenient  alternative  for  frequently  used  long  names.  However,  components  of  renamed  records 
are  still  designated  with  the  syntax  of  record  components,  thus  avoiding  possible  confusion  with 
variables  bearing  the  same  name  as  the  components. 

In  addition  to  the  notational  advantage,  a renaming  declaration  avoids  re-evaluating  the  access 
path  to  a record  variable  for  each  component  selection,  and  thus  simplifies  the  generation  of 
efficient  code. 

Renaming  declarations  are  also  possible  for  subprograms,  modules,  and  exceptions.  In  addition 
subtype  declarations  can  be  used  to  rename  types. 

procedure  MR  renamee  MULTIPLEXER. READ; 

task  L_C  renames  LINK_CONTROLLER(6); 

l_0_MALFUNCTI0N  : exception  renames  INPUT_OUTPUT.MALFUNCTION; 

The  ability  of  renaming  turns  out  to  be  essential  when  working  with  modules  that  are  developed 
independently  by  different  groups  of  programmers.  Being  independently  developed,  such  modules 
may  declare  the  same  identifiers.  If  later  they  appear  in  a use  clause  within  a given  unit  it  may 
often  be  convenient  to  resolve  the  name  clashes  by  renaming  rather  than  using  the  dot  notation 
whenever  these  identifiers  appear.  For  example  consider 

package  TRAFFIC  Is 

type  COLOR  is  (RED.  AMBER.  GREEN); 
and  TRAFFIC; 
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package  WATER_COLORS  is 

type  COLOR  is  (WHITE.  RED,  YELLOW,  GREEN,  BLUE,  BROWN); 
and  WATER_COLORS; 

declare 

use  TRAFFIC.  WATER_COLORS; 
subtype  T_COLOR  is  TRAFFIC.  CO  LOR; 
subtype  W_COLOR  is  WATER_COLORS.COLCR 
X . T_COLOR; 

Y : W_COLOR; 

begin 

end; 


T;C,0l°R  a"'L*-£0L0R  re"a™  c°"e»POnding  types  and  are  unambiguous 
within  the  block,  (whereas  COLOR  would  be  ambiguous). 

Because  of  the  possibility  of  overloading,  it  will  often  suffice  to  rename  conflicting  type  names' 

nlSUbPTmS  bT9  thereafter  resolved  by  the  overloading  rules.  The  renaming  facility 
can  also  be  used  to  provide  a name  more  appropriate  to  the  context  of  its  use.  For  instance  the 
author  of  a sort  routine  may  call  his  version  QUICKSORT2  whereas  SORT  may  be  better  land  less 
cumbersome)  throughout  the  application. 


9.3.7  Linear  Elaboration  of  Declarations 


For  reasons  of  readability  (not  for  compilation  reasons),  the  elaboration  of  declarations  is  per- 

^!inteih-ear  h '"f  °ne-?assfash'°n ■ (This  means  that  the  scope  of  a declaration  extends  from  the 
point  where  the  declaration  is  made  (including  the  declaration  itself),  to  the  end  of  the  unit  con- 

hlT*9  th®.  declarat,°n-  Thjs  simple  rule  has  the  advantage  of  corresponding  to  the  understanding 
that  a reader  may  have  of  the  text  when  reading  the  program  sequentially. 


For  constant  declarations,  the  one  pass  strategy  is  quite  intuitive.  It  permits  later  type  and  constant 
declarations  to  be  expressed  in  terms  of  a previous  constant  declaration,  as  in  the  following  exam- 
ple whore  each  declaration  is  made  in  terms  of  the  one  on  the  previous  line. 


declare 

LENGTH  ; constant  INTEGER  ;=  100; 

SQUARE  constant  INTEGER  :=  LENGTH* LENGTH; 
subtype  SURFACE  is  INTEGER  range  0 ..  SQUARE' 
S.T.U  : SURFACE; 

begin 


end. 


The  one-pass  strategy  has  the  other  advantage  of  avoiding  cyclic  constant  declarations, 
a precaution  is  needed  for  inner  scopes 


However 
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declare 


N 

constant 

INTEGER  :=  10, 

begin 

declare 

M : 

constant 

INTEGER  :=  N**2; 

••  value 

equal  to  100 

N : 

constant 

INTEGER  :=  20. 

--  illegal 

redeclaration* 

and; 


Whereas  redeclaration  of  an  identifier  is  generally  permitted,  in  the  above  case  the  redeclaration  of 
N is  illegal  and  shall  be  rejected  by  the  translator,  since  the  value  of  the  outer  N has  already  been 
used  in  the  same  declarative  part.  The  rule  applied  is  as  follows: 

Identifiers  of  an  outer  scope  which  are  used  in  a given  sequence  of  declarations  may  not  be 
redefined  in  that  sequence  of  declarations. 

Linear  elaboration  means  that  mutually  recursive  procedures  must  have  their  specifications 
appearing  before  their  bodies.  Similarly,  this  means  that  the  module  bodies  of  two  packages  (or 
tasks)  can  mutually  refer  to  their  visible  parts,  provided  that  their  module  specifications  appear 
before,  as  in  the  following  example: 

package  A is 

and  A; 

package  B is 

usa  A; 

and  B: 


package  body  A is 
usa  B; 

and  A; 

package  body  B is 
usa  A; 

and  B. 

If  two  access  types  are  mutually  dependent,  an  incomplete  declaration  of  one  of  them  must  be 
given  before  the  corresponding  type  declaration  appears  in  full.  This  is  illustrated  in  the  following 
example: 
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type  CAR; 


— incomplete  declaration  of  CAR 


type  PERSON 
record 
NAME 
AGE 

SPOUSE 

VEHICLE 

end  record; 


it  access 


STRINGd 

INTEGER 

PERSON; 

CAR; 


20); 


130; 


type  CAR  is  access 


NUMBER 

OWNER 


INTEGER; 

PERSON; 


If  the  incomplete  predeclaration  of  CAR  were  omitted,  then  in  the  presence  of  an  outer  identifier 
CAR  of  any  type,  the  wrong  association  would  be  made  when  encountering  the  declaration  of  the 
component  VEHICLE,  but  this  would  be  trapped  when  the  definition  of  the  access  type  CAR  was 
encountered.  On  the  other  hand,  if  an  outer  type  CAR  existed  (and  the  inner  one  did  not)  it  is  clear 
that  the  association  with  the  outer  one  would  be  valid. 


The  importance  of  the  predeclaration  can  be  seen  by  noting  the  assumptions  that  the  reader  who 
has  read  the  definition  of  PERSON  but  not  that  of  the  inner  definition  of  CAR  would  make  in  the 
absence  of  the  predeclaration. 


10.  Separata  Campilation  and  Libraries 


10.1  Introduction 


Separate  compilation  of  program  units  is  a practical  necessity.  Its  basic  goal  is  to  permit  the 
separation  of  large  programs  into  simpler,  more  manageable  parts  and  to  provide  a library  facility. 
Separate  compilation  helps  to  reduce  compilation  costs  and  to  simplify  development  and  manage- 
ment of  program  corrections  and  updates. 

For  large  projects  involving  several  programmers,  separate  compilation  enables  a physical  separa- 
tion of  program  texts  in  a way  that  reflects  the  division  of  work  and  responsibilities  Once  the  com- 
mon interface  between  two  parts  has  been  agreed  upon  and  recorded  the  two  parts  can  be 
developed  and  compiled  separately.  The  fact  that  the  com, non  interface  is  a physically  separate 
text  guarantees  that  separate  recompilation  of  either  part  ; . es  not  invalidate  the  common  inter- 
face. 

The  physical  separation  of  program  texts  may  be  viewed  as  a support  facility  for  the  structured 
programming  concept  of  refinement.  It  may  also  be  used  to  conceal  the  text  of  subprograms  from 
users  who  are  only  allowed  to  call  them.  Such  concealment  may  be  justified  either  by  confiden- 
tiality or  in  order  to  prevent  inference  of  implicit  assumptions  regarding  the  functioning  of  the  sub- 
programs. Finally  this  physical  separation  enables  the  construction  of  libraries. 

It  is  appropriate  at  this  stage  to  introduce  the  distinction  between  independent  and  separate  com- 
pilation, a distinction  first  made  by  JJ.  Horning. 

Independent  compilation  has  been  achieved  by  most  assembly  languages  and  also  by  languages 
such  as  Fortran  and  PL/1.  Compilation  of  individual  modules  is  performed  independently  in  the 
sense  that  such  modules  have  no  way  of  sharing  knowledge  of  properties  defined  in  other 
modules. 

Independent  compilation  is  usually  achieved  with  a lower  level  of  checks  between  units  than  is 
possible  within  a single  compilation  unit.  In  consequence,  independent  compilation  came  into  dis- 
repute and  was  rejected  by  safety  minded,  early  typed  language  definitions  such  as  Algol  68  and 
Pascal.  Fast  compilation  of  the  complete  program  was  often  advocated  by  promoters  of  these 
languages  as  a safe  alternative  to  independent  compilation.  Fast  compilation,  however,  has  its 
limits,  and  it  fails  to  answer  the  needs  of  confidentiality  and  libraries. 

Separate  compilation,  on  the  other  hand,  reconciles  type  safety  and  the  pragmatic  reasons  for 
compiling  in  parts.  It  is  based  on  the  use  of  a library  file  which  contains  a record  of  previous  com- 
pilations of  the  units  which  form  a program.  It  has  been  developed  in  the  language  Sue  |CH  72  j 
and  in  later  languages  such  as  Jossle  |PW  74],  Lis  [IRHC  74],  Mesa  |GM  77,  LS  79]  and  recent 
extensions  of  Algol  68.  We  next  discuss  its  properties  in  terms  of  what  is  proposed  in  the  Green 
language. 
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When  a program  unit  is  submitted  to  the  translator,  the  translator  also  has  access  to  the  library  file 
Consequently  it  is  able  to  perform  the  same  level  of  checking,  in  particular  type  checking,  whether 
a program  is  compiled  in  many  parts  or  as  a whole  It  is  indeed  the  existence  of  the  library  file  that 
makes  the  compilation  separate  but  not  independent. 

Using  the  general  information  available  in  the  library  file  the  translator  will  be  able  to  help  the  user 
manage  recompilations.  In  particular  it  will  be  able  to  display  information  about  the  current  com 
pilation  state  of  a program  divided  in  several  compilation  units:  which  separate  program  units  have 
been  compiled  and  which  need  to  be  recompiled  because  of  prior  recompilations 

It  is  thus  for  reasons  of  safety  and  practicability  that  the  Green  language  has  a strong  facility  for 
separate  compilation.  Two  additional  criteria  have  been  followed  in  this  design,  namely  simplicity 
of  use  and  simplicity  of  implementation. 

Separate  compilation  being  a user  oriented  facility,  it  should  be  very  simple  to  understand  and  to 
use  Consequently  it  should  not  introduce  other  concepts  than  those  required  by  the  nature  of 
separate  compilation.  Scope  rules  and  the  general  form  of  separately  compiled  program  units 
should  be  the  same  as  those  of  normal  program  units. 

The  design  must  also  be  compatible  with  having  a simple  translator.  The  additional  work  required 
for  separate  compilation  should  stay  within  reasonable  limits,  since  one  of  the  goals  is  to  save 
globally  on  compilation  and  recompilation  time. 


10.2  Presentation  of  the  Separate  Compilation  Facility 


A complete  program  is  either  a procedure  body  or  it  is  a succession  of  compilation  units  submitted 
individually  or  together  to  the  compiler  In  the  Green  language  the  major  forms  of  program  units, 
that  is  subprograms  and  modules,  can  be  compilation  units.  In  addition,  a module  body  can  be 
compiled  separately  from  the  corresponding  module  specification. 

For  program  units  that  are  separately  compiled  it  >s  especially  important  to  exercise  precise  control 
over  the  names  that  are  visible  Consequently  compilation  units  are  restricted  program  units,  and 
the  visibility  rules  that  apply  to  them  are  those  that  apply  to  all  restricted  program  units. 

Although  compilation  units  are  submitted  individually  to  the  translator  they  can  depend  on  each 
other  through  their  visibility  lists.  For  this  reason  the  compilation  units  which  form  a given  program 
are  said  to  belong  to  a common  program  library. 

Traditionally,  one  can  distinguish  two  main  styles  of  program  development,  top-down  (or 
hierarchical)  program  development  and  bottom-up  program  development.  The  separate  compila- 
tion facility  should  support  both  styles,  and  also  any  intermediate  form. 


10.2.1  Bottom-up  Program  Development 


For  this  form  of  program  development  we  may  have  programmers  developing  libraries  of  generally 
usable  modules.  The  module  construct,  especially  in  the  package  form,  is  the  main  construct  to  be 
used  for  this  style  of  program  oevelopment. 
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Each  generally  usable  package  can  (and  should)  be  compiled  separately  and  made  thus  available  in 
the  program  library.  The  specification  and  the  body  (if  any)  of  such  a package  can  be  compilation 
units  and  they  can  be  submitted  either  in  the  same  or  in  two  different  compilations. 


Some  packages  produced  in  this  form  of  program  development  do  not  depend  on  any  outside 
information,  except  perhaps  that  of  the  predefined  environment;  for  example,  a package  of  physical 
constants.  More  generally,  packages  may  depend  on  information  defined  by  other  modules  of  the 
program  library.  For  example  an  application  level  input  output  package  may  depend  on  a more 
basic  input  output  package;  similarly  a surveying  package  could  depend  on  this  application  level 
input  output  package  and  on  another  package  defining  trigonometric  functions. 


Compilation  units  are  interdependent  through  their  visibility  lists.  This  is  shown  in  the  example 
below: 

restrlcted(MATH.LIB,  TEXTJO) 
procedure  QUADRATIC_EQUATION  la 
use  TEXTJO; 

A.  B,  C.  D : FLOAT; 

GET(A);  GET(B);  GET(C); 

0 :=  6**2  - 4.0*A*C; 
if  D < C.O  then 

1 PUT  ('IMAGINARY  ROOTS'); 

declare 

use  MATH-LIB;  - note:  SORT  is  defined  in  MATH_LIB 

b#Qio 

PUT  ('REAL  ROOTS  : '); 

PUT  ((B  - SQRT(D))/(2.0*A)); 

PUT  ((B  + SQRT(D))/(2.0*A)); 

PUT  (NEWLINE); 

end. 

#fHj  |f. 

and  QUADRATIC-EQUATION; 

For  the  programmer  writing  QUADRATIC_EQUATION,  this  procedure  represents  his  complete 
program.  However,  in  order  for  that  program  to  work,  the  program  library  should  already  contain 
the  two  packages  MATH_LIB  and  TEXTJO  on  which  QUADRATIC-EQUATION  depends. 
Otherwise  the  function  SORT  supplied  by  MATH  J.IB  and  the  procedures  GET  and  PUT  supplied 
by  TEXTJO  will  not  be  visible.  The  procedure  could  only  be  considered  as  complete  and  not 
dependent  on  any  other  module  if  the  packages  that  it  used  were  local  packages,  and  if  in  conse- 
quence it  had  no  visibility  list. 

Realizing  that  this  program  might  be  generally  usable,  the  programmer  may  decide  to  encapsulate 
it  within  a package,  perhaps  along  with  other  similar  procedures. 

package  EQUATION-SOLVER  la 
procedure  QUADRATIC-EQUATION; 
procedure  LINEAR-EQUATION; 
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restricted!  MATH_LIB.  TEXTJO) 
peckage  body  EQUATION.SOLVER  ia 


1 


procedure  QUAORATIC.EQUATION  is 

— same  text  as  before 
and; 

procedure  LINEAR_EQUATION  ia 

— reads  a linear  equation,  soives  it,  prints  results 
end, 

end  EQUATION_SOLVER; 

A program  using  this  is  shown  below: 

restricted!  EQUATIO  N_SO  LVE  R ) 
procedure  MAIN  ia 

use  EQUATION_SOLVER; 

begin 

for  I in  1 ..  10  loop 
QUADRATIC_EQUATION; 
end  loop; 
end  MAIN; 

Note  that  the  program  MAIN  need  only  mention  the  package  EQUATION_SOLVER  in  its  visibility 
list.  It  need  not  (and  should  not)  mention  the  packages  MATH_UB  and  TEXTJO,  which  are  actual- 
ly needed  by  the  package  body  of  EQUATION_SOLVER,  since  MAIN  does  not  contain  direct  calls 
to  subprograms  defined  in  either  MATH_LIB  or  TEXT_IO. 

The  outermost  declarations  made  in  compilation  units  introduced  in  this  fashion  must  be 
elaborated  before  execution  of  the  program.  When  preparing  an  object  program  for  execution  the 
translator  (and/or  linkage  editor)  must  collect  all  modules  called  directly  or  indirectly  and  elaborate 
them  before  program  execution.  In  the  example  above  of  the  procedure  MAIN,  the  modules 
EQUATION_SOLVER,  MATH_LIB,  TEXTJO  (and  possibly  also  other  modules  used  by  the  latter) 
must  be  elaborated.  Elaboration  of  these  modules  must  proceed  in  an  order  consistent  with  the 
partial  ordering  discussed  in  10.2.3. 

Note  finally  that  separately  compiled  modules  may  also  be  generic.  Instances  of  such  generic  com- 
pilation units  can  be  obtained  as  usual: 

restricted!  I NPUT_OUTPUT) 
procedure  TREAT_ELEMENTS  is 
type  ELEMENT  is  ... 

package  ELEMENTJO  is  new  INPUT_OUTPUT(ELEMENT); 

— use  of  the  input  output  procedures  for  objects  of  type  ELEMENT 
end  TREAT.ELEMENTS; 
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10.2.2  Hierarchical  Program  Development 

The  other  form  of  program  development  is  called  Werarchical  or  top  down,  as  used  in  programm- 
ing by  stepwise  refinement  [Wi  7 1 , Wo  72J.  The  top  level  provides  a formulation  of  the  program  in 
terms  of  operations  to  be  supplied  by  the  next  lower  level.  Each  such  operation  is  then  further 
defined  in  terms  of  operations  of  another  lower  level,  etc.  Corresponding  to  this  form  of  program 
development  the  Green  language  offers  the  possibility  of  having  compilation  units  that  are  sub- 
units of  other  compilation  units. 

We  illustrate  subunits  by  means  of  a variant  of  the  example  of  section  10.2  of  the  Reference 
Manual.  Assume  that  we  are  developing  the  procedure  TOP  in  a top  down  fashion.  The  top  level  of 
definition  is  given  by  the  following  compilation  unit: 

procedure  TOP  is 

type  REAL  is  digits  10: 

R.  S : REAL: 

procedure  Q(U  : REAL); 

picfcipi  0 is 

PI  : constant  REAL  :=  3 14159.26536; 
function  F(X  : REAL)  return  REAL; 
procedure  G(Y,  Z : REAL); 
end  D; 

package  body  D is  separata:  - stub  of  0 

procedure  OIL)  : REAL)  is  separate;  ~-  stub  of  Q 

begin  - TOP 

Q(R); 

D.GiR.  S); 
end  TOP; 

The  specifications  of  the  procedure  Q and  of  the  package  D are  given  as  usual.  Hence  the  state- 
ments of  TOP  can  be  defined  in  terms  of  these  units,  that  is,  the  procedure  Q and  the  subprograms 
F and  G defined  by  the  package  0 can  be  called.  In  this  case  however  the  bodies  of  Q and  D have 
not  been  provided,  but  only  body  stubs  in  their  stead,  so  that  these  two  program  units  can  be  com- 
piled separately  as  subunits  of  the  procedure  TOP.  The  procedure  Q appears  as 

restricted  (TOP) 

separate  procedure  Q(U  : REAL)  is 
use  0; 
begin 

U :=  FUJI. 

end  0; 

Although  separately  compiled,  Q must  still  have  access  to  the  identifiers  declaied  within  TOP.  For 
example  it  must  see  the  type  REAL  and  the  package  name  D.  This  is  achieved  by  the  visibility  list 
restricted  (TOP)  mentioning  the  name  of  the  enclosing  procedure  TOP.  Similar  considerations  app- 
ly to  the  separately  compiled  body  of  the  package  D: 
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restricted  (TOP) 

separate  package  body  0 is 

— some  local  declarations  of  0 followed  by 

function  F(X  : REAL)  return  REAL  is 


— sequence  of  statements  of  F 
end  F; 

procedure  G(Y,  Z : REAL)  Is  separate;  — stub  for  G 
end  D; 

In  this  case  the  package  body  contains  the  body  of  the  function  F and,  again,  a stub  for  the 
procedure  G which  is  thus  a subunit  of  D: 


restricted  (TOP,  INPUT_OUTPUT) 

separate  procedure  G(Y,  Z ; REAL)  is 


--  sequence  of  statements  of  G 

end  G; 

Subunits  can  be  declared  at  the  outermost  level  of  another  unit  or  subunit.  This  creates  the  pos- 
sibility of  a hierarchy  of  program  subunits  depending  on  a given  compilation  unit.  This  hierarchy  is 
no  different  from  the  nesting  hierarchy  in  ordinary  program  units.  In  particular,  the  visibility  rules 
are  the  same  and  a subunit  can  depend  on  dynamic  information.  For  example,  consider 

restricted  (TOP) 

separate  procedure  Q(U  ; REAL)  is 
use  D ; 

L : constant  REAL  :=  U**2; 

procedure  S is  separate; 
begin 

end  Q; 

Access  to  the  local  constant  L is  still  possible  within  S,  exactly  as  if  the  body  of  S were  textually 
nested  at  the  place  of  the  stub. 

restricted  (TOP) 
asperate  procedure  S is 


--  access  to  L is  possible 

end  S; 

It  should  be  clear  that  these  two  methods  for  introducing  compilation  units  are  not  mutually 
exclusive  and  can  be  used  in  combination.  For  example,  a general  purpose  package  may  be  split 
into  subunits  in  order  to  facilitate  its  development,  compilation  and  subsequent  recompilation. 


10-6 


1 0.2.3  Compilation  Ordor 


Compilation  units  may  be  compiled  separately,  but  this  does  not  mean  that  compilations  can  be 
submitted  in  an  arbitrary  order,  since  units  are  not  independent.  In  particular,  we  have  seen  that 
one  unit  may  appear  in  the  visibility  list  of  anothei  unit,  and  some  units  can  be  subunits  of  other 
units.  These  two  forms  of  dependence  determine  a partial  ordering  of  compilations: 

a A unit  cannot  be  compiled  before  any  unit  that  it  sees. 

a A module  body  cannot  be  compiled  before  the  corresponding  module  specification. 

a A subunit  cannot  be  compiled  before  the  unit  containing  its  declaration  (and  stub). 

These  rules  are  certainly  rules  of  common  sense  and  the  translator  must  enforce  them.  It  should  be 
clear  that  they  only  define  a partial  ordering  and  that  several  sequences  are  actually  possible.  For 
example 

(a)  The  procedure  QUADRATIC_EQUATION  cannot  be  compiled  before  the  specifications  of 
MATH_LIB  and  TEXTJO.  On  the  other  hand,  the  latter  can  be  submitted  in  any  order. 
Furthermore  the  package  bodies  of  MATH_LIB  and  TEXT_IO  need  not  themselves  be  com 
piled  before  QUADRATIC_EQUATION.  Of  course,  in  order  to  execute  the  program  it  will  be 
necessary  that  all  compilations  be  completed. 

(b)  The  procedure  TOP  must  be  compiled  before  its  subunits  Q and  D can  be  compiled.  On  the 
other  hand,  the  order  of  compilation  of  the  procedure  body  of  Q and  of  the  package  body  of  D 
is  irrelevant.  Note  that  the  body  of  Q contains  the  clause  use  D;  but  this  has  no  influence  on 
order  of  compilation  since  all  the  information  that  Q needs  to  know  (and  can  know)  about  0 is 
contained  in  the  specification  of  D compiled  with  TOP. 

(c)  The  subunit  G cannot  be  compiled  before  either  the  package  body  of  D (containing  its  stub)  or 
INPUT_OUTPUT  (appearing  in  its  visibility  list).  On  the  other  hand  the  body  of  D and  the 
INPUT_OUPUT  package  can  be  compiled  in  any  order. 


1 0.2.4  Recompilation  Order 


Similar  considerations  apply  for  recompilations.  If  a given  declaration  is  modified  in  a program  unit, 
all  other  units  actually  using  the  declared  entity  are  affected  by  the  change  and  should  be  recom- 
piled. 

In  principle,  a translator  including  a librarian  facility  could  compare  the  old  text  and  the  new  text 
and  keep  track  of  the  changes  on  an  individual  basis.  It  would  thus  be  able  to  keep  recompilations 
to  an  absolute  minimum. 

For  simpler  translators  however,  one  may  asstime  that  the  smallest  grain  ot  change  recognized  by 
the  translator  is  the  recompilation  of  a compilation  unit  for  Imnslntois  using  sin  li  n suaie^  ||,o 
rules  defining  the  need  for  recompilations  are  identical  to  the  rules  defining  the  compilation  on  Ini 
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Given  the  ability  to  separately  compile  a module  specification  and  a module  body  this  simple 
strategy  should  not  in  practice  require  many  more  recompilations  than  strictly  necessary 

Note,  in  this  respect,  that  the  language  design  has  carefully  avoided  unnecessary  textual 
dependency.  For  example,  the  fact  that  visibility  restrictions  are  given  with  the  procedure  body  and 
not  with  the  procedure  declaration  (and/or  stub)  is  quite  important.  Consider  the  alternative 

procedure  EXAMPLE  it 

package  A it 

end  A: 
package  B it 

end  B; 

— The  following  is  not  in  Green: 

restricted  l A.  INPUT  OUTPUT) 

procedure  P(X  : INTEGER)  it  eeparate; 

restricted  ( EXAMPLE . MATH  LIB) 

procedure  Q(Y  : REAL)  it  separate 

end  EXAMPLE; 

Assume  that  in  some  later  revision  of  this  program,  input  output  needs  to  be  performed  within  the 
body  of  Q.  Then  if  visibility  lists  were  provided  with  the  stubs,  it  would  be  necessary  to  modify  the 
stub  of  Q and  hence  to  recompile  the  text  of  the  EXAMPLE.  However  since  the  stub  of  P is  also 
provided  there  (this  is  the  textual  dependence),  a translator  using  the  simple  strategy  would  con- 
clude the  necessity  of  recompiling  P as  well. 

While  we  recognize  that  future  translators  might  adopt  more  ambitious  schemes,  this  design  has 
carefully  avoided  any  feature  that  would  not  be  compatible  with  the  simple  strategy.  Given  this 
careful  avoidance  of  unnecessary  textual  dependencies  the  number  of  recompilations  can  be  kept 
quite  close  to  the  actual  minimum. 


10.2.5  Methodological  Impact  of  Separate  Compilation 


The  ability  to  separately  compile  a module  specification  and  the  corresponding  module  body  has 
important  methodological  consequences  for  program  development  and  maintenance.  For  example, 
it  allows  a team  of  programmers  to  agree  upon  a common  interface  and  define  it  by  one  or  more 
package  specifications.  This  being  done,  the  package  bodies  and  any  other  unit  using  the  common 
interface  can  be  developed  in  parallel  and  compiled  in  an  arbitrary  order.  Consider  for  example  the 
specification  of  table  management  package  given  in  section  7.5  of  the  Reference  Manual: 
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package  TABLE_MANAGER  is 
typa  ITEM  is 
record 

ORDER_NUM  : INTEGER; 

ITEM_CODE  ; INTEGER; 

ITEM_TYPE  : CHARACTER; 

QUANTITY  ; INTEGER; 

and  record; 

NULL^ITEM  : constant  ITEM  := 

(ORDER.NUM  | ITEM_CODE  | QUANTITY  =>  0,  ITEM.TYPE  =>  " ”); 

procedure  INSERT  (NEW.ITEM  ; in  ITEM); 
procedure  RETRIEVE  (FIRSTJTEM  : out  ITEM); 

TABLE_FULL  ; exception;  — may  be  raised  by  INSERT 
end  TABLE_MANAGER; 

The  above  package  specification  contains  all  the  declarations  that  need  to  be  known  by  any  unit 
using  the  services  of  the  table  manager. 

!t  is  important  to  realize  that  the  package  body  of  TABLE_MANAGER  may  be  modified  and  recom- 
piled without  need  for  recompilations  of  units  using  TABLE_MANAGER.  As  long  as  the  operations 
promised  by  the  visible  part  of  the  definition  module  are  correctly  achieved,  the  user  will  not  be 
affected  by  such  changes.  Another  version  of  the  package  body  using  a different  technique  (such 
as  a balanced  tree  instead  of  lists)  may  be  substituted  without  f fecting  the  user. 

This  ability  to  compile  a module  specification  and  the  corresponding  module  body  separately  is  a 
logical  extension  of  the  idea  of  encapsulation.  Since  the  user  is  not  affected  by  the  contents  of  the 
package  body  (provided  it  is  correct),  there  is  no  need  to  show  him  its  text:  all  the  user  needs  is  an 
object  module. 

Separate  compilation  of  module  bodies  may  thus  be  used  to  achieve  physical  hiding.  This  will  be 
useful  for  confidentiality  purposes.  It  will  also  help  to  deny  the  user  the  possibility  of  reading  the 
algorithms  and  inferring  implicit  assumptions  that  might  not  be  satisfied  by  later  implementations. 
In  this  sense  separately  compiled  module  bodies  provide  good  support  for  the  policy  of  restricted 
flow  of  information  advocated  by  Parnas  [PA  73].  They  can  be  used  in  conjunction  with 
methodologies  such  as  algebraic  specification  [GU  77]. 


10.3  The  Program  Library 


In  the  previous  sections  we  have  shown  how  a large  program  can  be  separated  into  several  com- 
pilation units.  All  such  units  logically  belong  to  what  is  called  a program  library.  Such  library  may 
contain  the  units  necessary  for  a single  main  program,  but  it  may  also  contain  the  units  of  several 
main  programs,  especially  in  the  case  of  related  projects.  This  should  be  left  as  a user  decision. 

Associated  with  each  program  library,  there  must  be  a library  file  that  records  information  relative 
to  the  compilations  that  have  already  been  done.  In  particular,  the  library  file  must  contain  symbol 
tables  for  separately  compiled  module  specifications.  It  must  also  record  compilation  dates,  and 
the  unit-subunit  relations,  in  order  to  enable  the  translator  to  check  the  order  of  compilation. 
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When  submitting  a compilation  unit  to  the  compiler  the  programmer  must  provide 

• The  source  text  of  the  compilation  unit 

• The  name  of  the  library  tile  to  which  the  unit  belongs 

It  is  this  second  item  that  makes  the  compilation  separate  but  not  independent;  the  library  file 
enables  the  translator  to  perform  type  checking  ncross  separately  compiled  units  exactly  as  within 
a given  compilation  unit 

The  concept  of  program  library  as  defined  above  is  not  much  different  from  the  usual  concept  of 
library,  provided  that  means  exist  for  transferring  units  from  one  library  to  another  one.  Such 
facilities  are  not  properly  within  the  domain  of  the  language  but  rather  within  that  of  its  support 
environment.  We  can  only  state  here  desired  facilities  that  this  environment  should  provide.  When 
standardized  these  facilities  could  be  specified  by  appropriate  pragmas: 

Library  creation: 

There  should  be  a command  for  library  creation.  Some  translators  may  decide  to  initialize 
the  library  with  the  predefined  modules  upon  library  creation. 

Inclusion  of  library  units. 

There  should  be  a command  to  include  a unit  of  one  library  into  another  library.  Note  that 
such  inclusion  requires  inclusion  of  the  information  pertaining  to  the  unit  |e.g.  its  symbol 
table).  After  its  inclusion,  a unit  should  be  indistinguishable  from  other  units  of  the  library 
Inclusion  of  a unit  may  require  inclusion  of  units  that  It  sees. 

Deletion  of  library  units 

Conversely  there  should  be  a command  to  delete  a unit  from  a given  library. 
Completion  check 

There  should  be  a command  by  which  a programmer  states  that  the  program  is  complete 
(all  units  have  been  compiled).  The  translator  will  check  that  this  is  the  case  and  issue 
appropriate  error  messages  otherwise.  Similarly  this  command  (or  a distinct  one)  could  be 
used  to  display  global  information  about  the  current  state  of  the  program  library:  which 
units  have  been  compiled,  which  subunits  have  never  been  compiled  which  units  need  to 
be  recompiled,  etc. 

Completion  and  status  checks  are  quite  useful  since  a library  may  contain  obsolete  units  at 
intermediate  stages  of  the  program  development. 

Since  the  translator  is  able  to  detect  the  need  for  recompilations,  it  could  conceivably  do  these 
automatically  when  needed  However  changes  are  often  done  for  several  units  at  the  same  time.  A 
translator  that  oerformed  recompilations  after  each  change  might  perform  moro  recompilations 
than  necessary  unless  it  had  global  knowledge  of  all  changes  submitted. 

Assume  for  example  that  the  specifications  of  the  packages  A and  B are  modified  It  all  units  see 
* hj  A were  automatically  recompiled,  then  if  some  of  them  also  see  B.  they  would  bo  recompiled  a 
*e<  and  time  after  the  compilation  of  B. 

. n i certainly  preferable  to  let  the  user  manage  the  recompilations.  However,  this  means 
• <•'<*  for  displaying  the  current  status  of  compilation  units  of  a program  should  be  provided. 
■ • . * ""ans  that  the  user  should  be  able  to  state  that  a program  is  complete  and  let  the 

• • •-*>  x mat  this  is  actually  the  caso. 
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10.4  The  Implementation  of  Separate  Compilation 


The  purpose  of  this  section  is  to  demonstrate  that  the  proposed  language  features  can  readily  be 
implemented  safely  and  at  a reasonable  cost  for  the  simple  strategy  where  the  minimum  grain  of 
change  recognized  by  the  translator  is  a unit  compilation  or  recompilation.  The  model  described 
below  should  not  be  considered  as  the  only  possible  implementation  technique  but  rather  as  a 
feasibility  proof.  It  is  similar  to  the  technique  used  for  Lis  compilers 

As  mentioned  before,  separate  compilation  of  a program  split  into  separate  units  involves  a library 
file  recording  information  on  the  units  and  on  relations  between  them.  In  a sense,  the  library  file 
plays  a role  similar  to  that  of  the  symbol  table  for  a single  compilation  unit.  The  basic  idea  of  main- 
taining a library  file  is  not  widely  known,  but  has  been  in  use  for  many  years  for  the  compool 
facility  in  Jovial  | PE  66|. 


10.4.1  Principle  of  Separate  Compilation 

A library  file  is  essentially  a representation  of  the  declarations  encountered  in  the  outer  declarative 
part  of  the  compilation  unit  considered.  These  declarations  may  be  accessed  by  other  compilation 
units.  In  particular  access  may  be  made  to: 

e Any  unit  (or  subunit)  containing  declarations  of  local  subunits. 

• Any  separately  compiled  module  specification  since  it  may  appear  in  the  visibility  lists  of  other 
compilation  units. 

As  a consequence  the  corresponding  symbol  tables  must  be  kept  in  the  library  file.  It  is  the 
translator's  responsibility  to  maintain  these  symbol  tables.  In  order  to  perform  a given  compilation, 
it  must  first  select  the  symbol  tables  corresponding  to  the  current  scope  and  then  load  them.  In 
other  words,  it  must  construct  a r/mbol  table  equivalent  to  the  symbol  table  at  a given  program 
point  as  if  the  program  was  compiled  as  a complete  text. 

In  order  to  perform  this  task  it  is  useful  to  consider  the  following  forest  structure,  which  reflects 
declaration  of  units  and  subunits: 

(a)  A unit  is  a root. 

(b)  The  sons  of  a given  compilation  unit  are  the  subunits  whose  stubs  are  given  within  the  unit 
considered 

This  structure  is  necessary  for  the  determination  of  scope  rules.  Hence  it  must  be  recorded  in  the 
library  file  and  updated  as  new  stubs  of  subunits  are  encountered,  or  as  new  units  are  compiled. 

Finally  for  all  units  and  subunits,  a list  of  the  modules  mentioned  in  their  visibility  lists  must  be 
recorded. 

The  forest  structure  will  help  for  the  determination  of  the  symbol  tables  to  be  loaded,  tor  checking 
the  validity  of  visibility  restrictions  and  for  the  determination  of  the  recompilations  that  need  to  be 
done  as  a consequence  of  previous  recompilations.  Naturally,  the  translator  may  use  this  informa 
tion  to  assist  the  user  with  recompilations. 
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To  check  for  required  recompilations,  the  translator  may  use  a system  of  time-stamping  that 
records  the  order  of  compilations,  a compilation  date  is  associated  with  the  symbol  table  of  each 
unit  or  subunit. 

10.4.2  Details  of  the  Actions  Performed  by  the  Translator 


The  following  major  actions  must  be  performed  during  the  translation  of  a compilation  unit: 
Determination  of  the  compilation  context 

During  a preliminary  scan  of  the  text  of  the  compilation  unit  (for  instance,  during  the  lexical  or 
context-free  analysis  phase),  the  name  of  the  compilation  unit  is  recognized  and  a merged  list  of  all 
visibility  lists  found  in  the  inner  declarative  parts  of  the  unit  is  constructed.  Note  that  the  recogni- 
tion of  the  compilation  unit  name  will  sometimes  be  only  possible  by  using  the  contents  of  the 
visibility  lists. 

Using  the  forest  structure,  the  genealogy  of  the  compilation  unit  may  be  found:  its  father,  grand- 
father, and  so  on,  until  a unit  (root)  is  found.  This  genealogy  together  with  the  merged  visibility 
restrictions  comprise  the  compilation  context. 

Checking  the  validity  of  the  compilation  context 

Any  unit  mentioned  in  a visibility  list  within  a given  compilation  unit  must  be  either  a library 
module  or  the  root  of  the  genealogy.  Any  subunit  procedure  mentioned  in  a visibility  list  must 
belong  to  the  genealogy  of  the  current  compilation  unit.  Any  subunit  module  mentioned  in  a 
visibility  list  must  have  been  declared  in  one  of  the  units  or  subunits  of  the  genealogy. 

The  remaining  names  may  be  those  of  procedures  and  modules  that  are  local  to  the  current  unit. 
This  sublist  is  kept  for  later  checks. 

The  following  checks  of  compilation  dates  must  be  performed: 

• In  the  genealogy,  each  son  must  have  been  .ompiled  after  its  father. 

• Each  compilation  unit  of  the  genealogy  must  have  been  compiled  after  the  modules  it  men- 
tions in  its  visibility  list. 

• Each  module  of  the  merged  visibility  list  must  have  been  compiled  after  the  modules  it  men- 
tions on  its  own  visibility  list. 

Translation  may  only  proceed  if  all  these  checks  are  successful.  Otherwise  diagnostics,  a list  of 
required  recompilations  and  a recommended  order  must  be  printed  by  the  translator. 

Table  loading 

The  symbol  tables  of  the  portion  of  the  genealogy  used  and  those  of  the  modules  of  the  merged 
visibility  lists  may  now  be  assembled  (of  course,  actual  accessibility  to  the  declarations  contained 
in  a module  must  be  given  only  in  scopes  where  the  module  name  appears  in  a use  clause  or  in 
selected  components). 

This  table  assembly  may  involve  establishing  some  links  between  the  different  tables  since  they 
may  refer  to  one  another  (for  instance  an  identifier  declared  in  a given  package  may  be  of  a type 
declared  in  another  package). 
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Update  of  the  forest  structure,  table  unloading 


At  the  end  of  the  translation  of  a unit  or  subuntE,  the  date  of  compilation  must  be  updated.  For  a 
module,  or  for  a procedure  containing  local  declarations  of  separate  units,  a new  symbol  table 
must  be  stored  in  the  library  file  in  a suitable  format.  Newly  declared  separate  units  must  be 
entered  in  one  of  the  trees  of  the  forest.  If  a new  unit  is  compiled  a root  must  be  added  to  the 
forest. 

When  a module  is  recompiled  it  is  possible  to  use  the  forest  structure  to  mark  all  units  using  the 
module  as  needing  recompilation.  Similarly  when  a procedure  or  module  is  recompiled,  all  sub- 
units declared  within  it  may  be  marked  as  needing  recompilation. 


10.4.3  Treatment  of  Module  Bodies 


For  a given  module,  the  two  disjoint  units  (specification  and  body)  must  be  viewed  as  defining 
(complementary  aspects  of)  the  same  logical  entity.  Consequently  it  will  be  convenient  for  the  user 
to  have  a single  object  module,  and  not  two.  In  order  to  achieve  this  effect  the  code  produced  dur- 
ing the  compilation  of  the  module  specification,  if  any,  may  be  kept  in  some  intermediate  form  in 
the  library  file  entry  associated  with  the  module.  Later,  when  compiling  the  module  body,  this 
initial  code  may  be  recovered  and  the  compilations  may  proceed  as  if  the  two  units  were  con- 
catenated. 


10.4.4  Summary  of  the  Information  Contained  in  a Library  File 


The  library  file  contains  a representation  of  the  forest  structure  discussed  above.  Each  node  of  a 
tree  corresponds  to  a subunit,  except  the  root,  which  is  always  a unit.  A node  contains: 

• The  name  of  the  unit  or  subunit. 

a Its  nature:  subprogram,  package  or  task. 

a Its  compilation  date  and  that  of  the  associated  module  body,  if  there  is  one. 
a The  list  of  modules  mentioned  in  the  visibility  list. 

a A symbol  table,  if  the  unit  or  subunit  contains  declarations  of  subunits,  or  if  the  unit  or  subunit 
is  a module  specification. 

a A boolean  component  indicating  need  for  recompilation. 

The  entry  for  a given  node  is  created  either  when  the  stub  for  a subunit  is  analyzed  (and  then 
initialized  in  the  state  "recompilation  needed"),  or,  when  the  node  is  for  a unit,  during  its  compila- 
tion. This  entry  is  updated  during  compilations.  The  entry  for  a subunit  may  be  deleted  from  the 
compilation  file  if  its  declaration  is  absent  from  the  parent  unit  (or  subunit),  when  recompiling  the 
latter. 

Each  individual  symbol  table  must  be  kept  in  a format  that  simplifies  the  reestablishment  of  the 
relations  between  different  symbol  tables  when  they  are  assembled.  As  an  example,  consider  the 
two  following  packages: 
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package  0 is 

type  T is  ... 

end  D; 

restricted(D) 
package  E is 

use  D; 

X : T; 

end  E; 

Given  the  symbol  table  entry  for  the  declaration  of  X,  it  must  be  possible  to  find  the  symbol  table 
entry  for  its  type  T. 

If  internal  references  are  used  to  represent  such  relations,  they  must  be  relocated  when  the  symbol 
tables  are  assembled.  Solutions  involving  relocation  information,  or  alternatively  general  tables  of 
types,  have  been  used  in  the  past  by  implementations  of  languages  supporting  separate  compila- 
tion. 

Note,  finally,  that  symbol  tables  may  be  transferred  from  the  library  file  of  one  program  to  that  of 
another  program.  The  internal  structure  adopted  for  symbol  tables  should  permit  this. 


10.5  Summary  and  Conclusion 


To  summarize  the  Green  separate  compilation  facility: 

• Compilation  units  can  be  subprograms,  module  specifications  and  module  bodies.  All  com- 
pilation units  are  restricted  program  units.  The  compilation  units  of  a program  form  a program 
iibrary. 

• Subunits  of  other  compilation  units  can  be  defined  by  using  body  stubs.  These  subunits  are 
separately  compiled. 

• The  visibility  rules  applicable  to  compilation  units  and  subunits  are  the  usual  scope  rules 
applicable  to  all  restricted  program  units.  The  order  of  compilation  and  recompilation  is  only 
governed  by  these  rules. 

We  have  attempted  to  restrict  the  number  of  language  concepts  to  the  minimum  reouired  by  the 
nature  of  sep  irate  compilation,  and  believe  we  have  produced  quite  a simpie  solution.  Naturally 
this  simplicity  was  obtained  by  treating  separate  compilation  as  one  of  the  major  goals  in  the 
language  design,  and  not  as  an  afterthought. 

Separate  compilation  has  been  conceived  mainly  as  a user  facility  supporting  the  traditional  forms 
of  program  development. 

This  language  proposal  can  be  implemented  at  very  reasonable  cost,  as  evidenced  by  the  previous 
sections  and  by  previous  languages  supporting  similar  separate  compilation  facilities.  In  conse- 
quence the  type  rules  may  be  enforced  across  separate  units  to  the  same  degree  as  within  a given 
unit. 
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Separate  compilation  in  no  way  changes  the  meaning  of  a program.  Furthermore  we  have 
demonstrated  that  the  information  contained  in  a library  file  may  be  used  to  check  that  a given 
compilation  does  not  use  information  from  other  units  that  have  in  the  meantime  become 
obsolete.  , 

Finally,  one  of  the  motivations  of  separate  compilation  Is  the  creation  of  software  libraries.  This  is 
supported  by  the  present  proposal.  By  far  the  most  useful  library  units  should  be  packages.  The 
proposed  facility  permits  their  use  with  the  same  degree  of  safety  as  for  internal  units. 

It  is  expected  that  library  packages  will  be  used  for  encapsulation  of  type  definitions,  for  common 
constants  and  data,  and  for  shared  declarations.  The  fact  that  these  library  items  are  already  com- 
piled program  units  and  not  source  texts  offers  a degree  of  safety  not  found  in  languages  providing 
merely  independent  compilations. 

Other  modules  will  be  used  for  the  creation  of  user  packages  such  as  input  output  packages,  to  be 
found  in  libraries.  The  ability  to  compile  a module  specification  separately  from  the  corresponding 
module  body  provides  the  possibility  of  separating  the  interface  of  a module  from  its  implementa- 
tion. Thus  it  supports  information  hiding  and  reliability  to  an  extremely  high  degree. 
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11.  Tasking 


11.1  Introduction 


Tasking  is  an  important  aspect  of  many  embedded  systems  and  this  importance  is  clearly 
recognized  in  the  Steelman  requirements.  However  it  seems  to  have  been  neglected  in  most 
languages  currently  in  production  use  for  such  systems.  One  reason  has  clearly  been  a lack  of  con- 
fidence in  the  many  different  facilities  put  forward  for  the  control  of  parallelism.  Semaphores, 
events,  signals  and  other  similar  mechanisms  are  clearly  at  too  low  a level.  Monitors,  on  the  other 
hand,  are  not  always  easy  to  understand  and,  with  their  associated  signals,  perhaps  seem  to  offer 
an  unfortunate  mix  of  high  level  and  low  level  concepts.  It  is  believed  that  Green  strikes  a good 
balance  by  providing  facilities  which  are  not  only  easy  to  use  directly  but  can  also  be  used  as  tools 
for  the  creation  of  mechanisms  of  different  kinds. 

The  basic  textual  concept  in  Green  is  that  of  a task  which  in  form  is  closely  analogous  to  a package 
module.  Statements  enable  tasks  to  be  initiated  in  parallel  with  their  parent  task  and  with  each 
other.  The  termination  of  tasks  basically  follows  the  scope  structure  but  mechanisms  are  also 
provided  to  allow  wayward  tasks  to  be  controlled. 

Communication  and  synchronization  are  both  a hieved  using  the  concept  of  a rendezvous 
between  a task  issuing  an  entry  call  and  a task  accepting  the  call  by  an  accept  statement.  An  entry 
call  is  similar  to  a procedure  call  except  that  the  calling  and  called  tasks  are  distinct  and  syn- 
chronized. 

Great  power  is  provided  by  the  select  statement  which  enables  a task  to  respond  to  several  dif- 
ferent possible  entry  calls. 

Other  facilities  include  a delay  statement,  which,  combined  with  the  select  statement,  provides  a 
time-out  mechanism  in  a natural  manner.  Interrupts  may  be  handled  by  a representation 
specification  associated  with  a particuiai  entry. 

This  chapter  starts  by  describing  the  facilities  and  illustrating  their  use  with  examples.  This  is  fol- 
lowed by  a brief  historical  survey  of  parallel  processing  mechanisms  which  put  the  present  Green 
operations  into  perspective.  A substantia,  example  is  then  given.  A further  section  covers  miscel- 
laneous points  of  rational  that  are  not  covered  elsewhere,  and  a final  section  discusses  some 
implementation  considerations. 
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1 1 .2  Presentation  of  the  Tasking  Facility 


This  section  introduces  the  tasking  facilities,  defines  them  generally,  and  illustrates  them  by  means 
of  examples.  After  a presentation  of  tasks  and  their  associated  hierarchy,  we  describe  rendezvous, 
entry  calls,  and  accept  statements.  The  discussion  continues  with  select  statements,  delay  state- 
ments, and  interrupts,  whose  occurrences  can  oe  viewed  as  implicit  entry  calls.  Families  of  tasks 
and  entries,  and  generic  tasks  are  then  described  and  the  presentation  concludes  with  the  use  of 
these  concepts  for  scheduling. 


11.2.1  Tasks  : Textual  Layout 


A task  is  a textually  distinct  program  unit  which  may  be  executed  concurrently  with  other  tasks.  It 
is  very  similar  in  form  to  a package  module.  Indeed  the  major  difference  between  a package 
module  and  a task  module  is  that  the  former  is  merely  a passive  construct  whereas  a task  may  be 
active. 

Like  the  package  module,  a task  may  be  declared  within  any  declarative  part  (except  the  visible 
part  of  another  task)  and  similarly  comprises  two  distinct  pieces  of  text.  These  are  the  specifica- 
tion part  which  describes  its  external  appearance,  and  the  module  body  which  describes  its  inter- 
nal behavior.  These  two  parts  will  often  be  juxtaposed  in  the  text  but  need  not  and  indeed  need 
not  be  compiled  together.  We  will  now  consider  the  details  of  these  two  parts  and,  in  particular, 
show  how  they  differ  from  the  corresponding  parts  of  package  modules. 

The  specification  part  comprises  a header  giving  the  name  of  the  task  (and  possibly  other 
characteristics,  to  be  discussed  later,  such  as  whether  it  is  a family  or  generic)  and  a declarative 
part  which  describes  its  appearance  to  the  outside  world.  This  declarative  part  is  usually  known  as 
the  visible  part.  The  visible  part  may  contain  type,  subtype,  constant,  entry,  subprogram,  exception, 
and  renaming  declarations.  The  declarations  of  variables  and  modules  are  disallowed  on 
methodological  grounds  (since  such  variables  would  not  be  controlled  by  the  task)  and  because  of 
the  difficulty  of  preventing  access  to  them  if  the  task  is  not  active.  Entries  externally  look  like 
procedures  but  are  executed  in  mutual  exclusion. 

It  is  the  possibility  of  the  inclusion  of  entry  declarations  which  distinguishes  the  visible  part  of  a 
task  from  that  of  a package  module. 

The  following  is  an  example  of  the  specification  part  of  a task: 

task  LINE_TO_CHAR  is 

typa  LINE  is  array  (1  ..  80)  of  CHARACTER; 

entry  PUT_LINE  (L  : in  LINE); 

entry  GET.CHAR  (C  : out  CHARACTER); 

end; 


The  module  body  of  a task  has  a form  similar  to  that  of  a package  body  and  comprises  a 
declarative  part  and  a sequence  of  statements.  The  body  of  the  above  example  has  the  following 
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task  body  LINE_TO_CHAR  is 
BUFFER  : LINE: 
begin 

— sequence  of  statements 

end; 

The  full  details  of  the  body  of  this  example  are  deferred  until  section  1 1.2.4. 


11.2.2  Task  Hierarchy 


Before  describing  the  detailed  statements  associated  with  tasks,  it  is  important  that  the  reader 
understand  the  underlying  concept  of  a task,  its  activation,  and  its  parent.  We  describe  this  in 
terms  of  a model  which  should  be  considered  to  be  only  illustrative. 

We  distinguish  between  a thread  of  control  and  the  text  of  a task.  A thread  of  control  conesponds 
to  a task  activation  whereas  the  text  is  merely  a passive  description  of  some  code.  The  main 
program  can  be  considered  to  be  an  anonymous  task  with  a thread  of  control  created  by  the 
underlying  system. 

When  a thread  of  control  enters  a scope  containing  task  declarations,  the  elaboration  of  each 
declaration  creates  just  one  new  potential  thread  of  control  (or  in  the  case  of  a family,  one  for  each 
member  of  the  family).  There  is  therefore  a one  to  one  correspondence  between  threads  of  control 
and  the  elaboration  of  task  declarations  and  we  can  loosely  talk  about  a thread  of  control  by  the 
name  of  the  corresponding  task  declarations. 

Although  each  elaboration  of  a task  declaration  only  gives  rise  to  one  thread  (that  is,  a task  cannot 
be  multiply  active)  nevertheless  there  may  be  several  threads  corresponding  to  different  coexisting 
elaborations  of  the  declaration.  Th;s  would  occur  for  example  if  a task  were  declared  in  a recursive 
procedure  or  perhaps  more  likely  in  a procedure  called  reentrantly  by  several  other  tasks.  The  nor- 
mal scope  rules  prevent  any  ambiguity  because  only  one  instance  of  the  task  elaboration  is  visible 
at  any  one  point. 

It  should  also  be  realized  that  a subprogram  does  not  in  any  sense  belong  to  any  particular  task. 
Whether  or  not  it  can  be  used  reentrantly  will  depend  upon  its  visibility.  If  it  is  within  the  body  of  a 
task  which  has  no  subtasks,  then  it  can  only  be  called  by  the  embracing  task.  On  the  other  hand,  if 
it  is  declared  in  the  same  declarative  part  as  several  tasks,  then  it  can  obviously  be  called  by  all 
these  tasks. 

The  parent  of  a task  is  the  task  whose  thread  of  control  elaborates  its  declaration.  We  recall  from 
Chapter  7 of  the  Reference  Manual  that  on  entry  into  a scope  containing  a package  module  the 
visible  part  is  first  elaborated  and  the  package  body  is  subsequently  executed  in  order  to  initialize 
the  package.  On  the  other  hand,  upon  entry  into  a scope  containing  the  declaration  of  a task, 
again  the  visible  part  is  immediately  elaborated  but  the  task  body  is  not  executed  until  the  task  is 
made  active  by  an  initiate  statement. 

The  initiate  statement  contains  a name  list  indicating  the  tasks  to  be  initiated.  The  tasks  are  then 
made  active  and  their  bodies  are  executed  in  parallel  with  each  other  and  their  parents.  It  should 
be  carefully  observed  that  the  task  performing  the  initiate  statement  need  not  be  the  parent 
although  it  often  is  (since  the  parent  is  the  one  who  elaborates  the  task  declaration,  frr  an  example 
see  section  1 1 .4.5). 


As  far  as  termination  is  concerned,  a task  will  terminate  on  reaching  its  final  end.  When  the  parent 
task  reaches  the  end  of  a scope  containing  the  declaration  of  local  tasks,  the  parent  may  have  to 
wait  until  all  the  local  tasks  have  terminated  if  they  have  not  already  done  so. 

For  example  consider  the  following  task  body  T containing  the  tasks  T1  and  T2. 

task  body  T is 

— declarations 

task  T1  is 


- visible  part  of  T1 


end; 


task  body  T1  is 

--  body  of  T1 

end: 


task  T2  is 

— visible  part  of  T2 

end; 

task  body  T2  is 

— body  of  T2 

end; 

begin 

initiate  T1,  T2; 

end. 


Execution  of  the  initiate  statement  causes  T1  and  T2  to  be  executed  in  parallel  with  T.  The  task  T 
continues  also  and  may  have  to  wait  at  its  final  end  for  T1  and  T2  to  terminate. 

Several  initiate  statements  may  occur,  thus  we  could  have  written 

initiate  T1; 
initiate  T2; 

However,  the  semantics  of  the  two  separate  initiate  statements  is  slightly  different.  In  the  case  of 
initiate  T1,  T2; 

we  are  assured  that  both  T1  and  T2  are  initiated  together  and  therefore  there  is  no  possibility  that 
one  could  call  an  entry  in  the  other  and  find  it  not  yet  active.  Of  course,  the  initiating  task  T is  also 
assured  that  the  initiated  tasks  are  also  active  before  it  obeys  its  next  statement. 


Initiation  of  a task  which  is  already  executing  causes  the  INITIATE_ERROR  exception  to  be  raised. 
However  a task  may  be  initiated  again  once  it  has  terminated  and  this  will  give  rise  to  a new 
execution  of  the  task. 
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Facilities  are  provided  to  enable  a task  to  exert  fine  control  over  the  termination  of  another  task. 
The  attribute  T'ACTIVE  is  TRUE  if  the  task  T has  been  initiated  and  has  not  yet  terminated.  The 
special  exception  FAILURE  may  be  raised  in  another  task  and  this  may  be  used  to  program  last 
wishes  followed  by  self  termination.  In  desperation  the  abort  statement  may  be  used.  Thus 

abort  T1,  T2; 

will  cause  tasks  T1  and  T2  plus  any  descendant  tasks  to  be  terminated  unconditionally.  This  may 
as  a consequence  raise  TASKING_ERROR  exceptions  in  other  tasks  which  were  communicating 
with  T1 , T2  or  their  descendants  at  the  time.  The  abort  statement  should  not  be  used  without  due 
care. 

The  above  discussion  was  presented  in  terms  of  several  tasks  executing  in  parallel.  Whether  this 
physically  occurs  depends  upon  the  hardware.  In  a multiprocessor  system  actual  parallel  execu- 
tion may  occur  whereas  in  a single  processor  system  only  one  task  can  really  be  active.  In  any 
case  a scheduler  is  required  in  order  to  allocate  the  ready  tasks  to  the  one  or  more  processors.  The 
scheduling  algorithm  takes  tasks  on  a first  in,  first  out  basis  within  priorities.  On  initiation,  tasks 
take  the  priority  of  their  initiator  but  they  can  change  their  own  priority  by  a call  of  the  procedure 
SET_PRIORITY.  The  priority  of  a task  T is  given  by  the  attribute  TPRIORITY.  Priorities  are 
provided  as  a tool  for  indicating  relative  degrees  of  urgency  and  on  no  account  should  their 
manipulation  be  used  as  a technique  for  attempting  to  obtain  mutual  exclusion. 

Families  of  tasks  and  generic  tasks  are  discussed  in  11.2.8  and  11.2.9. 


11.2.3  Visibility  Rules 


The  usual  visibility  rules  are  applicable  to  tasks.  As  a consequence  several  tasks  may  share  global 
variables  and  it  is  the  programmer's  responsibility  to  ensure  their  integrity.  Of  course  the  primary 
means  of  communication  between  tasks  is  not  through  the  sharing  of  global  variables  (which 
should  be  done  with  caution)  but  by  the  use  of  the  entry  as  described  in  the  next  section.  However 
to  disallow  shared  variables  seems  to  be  a constraint  which  would  be  unwise  in  some  critical  cir- 
cumstances. 

Shared  variables  are  not  marked  in  their  declaration  since  a local  variable  of  a generic  module 
could  be  shared  or  not  depending  on  the  place  where  an  instantiation  if  performed.  Moreover  anv 
global  variable  is  potentially  shared  and  its  appearance  in  a global  declaration  should  itself  be  a 
sufficient  warning.  If  it  were  used  by  a single  task  it  could  always  be  made  local  to  that  task. 


11.2.4  Entries  and  the  Accept  Statement 


As  we  have  seen  the  visible  part  of  a task  may  contain  the  specification  of  entries.  Externally  an 
entry  looks  like  a procedure,  takes  parameters  and  is  called  in  the  same  way.  The  difference  lies  in 
the  internal  behavior.  In  the  case  of  a procedure  the  calling  task  executes  the  procedure  body  itself 
and  the  procedure  body  can  be  executed  immediately.  In  the  case  of  an  entry  the  corresponding 
actions  are  executed  by  the  task  owning  the  entry,  not  by  the  calling  task.  Moreover  these  actions 
are  only  executed  when  the  called  task  is  prepared  to  execute  a corresponding  accept  statement. 
In  fact  the  calling  and  called  tasks  may  be  thought  to  meet  together  in  a rendezvous  We  will 
illustrate  this  by  completing  the  example  introduced  earlier. 
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task  LINE_TO_CHAR  is 

typa  LINE  is  array  (1  ..  80)  of  CHARACTER; 
entry  PUT_LINE  (L  : in  LINE); 
entry  GET.CHAR  <C  : out  CHARACTER); 
end; 

task  body  LINE_TO_CHAR  is 
BUFFER  : LINE; 

begin 

loop 

accept  PUT_LINE(L  . in  LINE)  do 
BUFFER  :=  L; 
end  PUT_LINE; 
for  I in  1 ..  80  loop 

accept  GET_CHAR(C  : out  CHARACTER)  do 
C :=  BUFFER(I); 
and  GET_CHAR; 

and  loop; 
and  loop; 
and; 

The  accept  statement  has  the  partial  appearance  of  a procedure  body.  It  can  be  thought  of  as  a 
body  to  be  executed  where  it  stands  in  much  the  same  way  as  a block  can  be  thought  of  as  an 
inline  procedure  without  parameters. 

The  accept  statement  repeats  the  formal  part  of  the  entry  declarations  in  order  to  emphasize  the 
scope  of  the  parameters.  The  formal  part  is  then  followed  by  the  statements  to  be  executed  during 
the  rendezvous.  These  are  delimited  by  do  and  end  and  are  the  scope  in  which  the  parameters  of 
the  entry  are  accessible. 

There  are  two  possibilities  for  a rendezvous  according  to  whether  the  calling  task  issues  the  calling 
statement  such  as 

LINE_TO_CHAR.PUT_LINE(MY_UNE); 

before  or  after  a corresponding  accept  statement  is  reached  by  the  called  task.  Whichever  gets 
there  first  waits  for  the  other.  When  the  rendezvous  is  achieved,  the  appropriate  parameters  of  the 
caller  are  passed  to  the  called  task  (note  that  actual  parameters  are  determined  when  the  entry  call 
is  issued,  not  when  the  rendezvous  occurs).  The  caller  is  then  temporarily  suspended  until  the  cal- 
led task  completes  the  statements  embraced  by  do  ...  end.  Any  out  parameters  are  then  passed 
back  to  the  caller  and  finally  both  tasks  again  proceed  independently  of  each  other. 

It  should  be  observed  that  the  rendezvous  is  named  in  one  direction  only.  The  calling  task  must 
knov;  the  name  of  the  entry  and  this  is  specific  to  the  called  task.  Thus  the  calling  task  must  know 
the  called  task.  The  called  task  on  the  other  hand  will  accept  calls  from  any  task.  Thus  we  have  a 
many-to-one  pattern  of  communication.  As  a consequence  of  this,  each  entry  potentially  has  a 
queue  of  tasks  calling  it.  This  queue  is  processed  in  a strictly  first  in  first  out  manner  and  each 
rendezvous  at  an  accept  statement  removes  just  one  item  from  this  queue. 
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The  behavior  of  the  process  LINE_TO_CHAR  should  now  be  clear.  It  contains  an  internal  buffer 
which  may  hold  a line  of  characters.  The  task  alternately  fills  the  buffer  by  accepting  a call  of 
PUT_LINE  and  then  empties  it  by  accepting  80  successive  calls  of  GET_CHAR.  Calls  of  the  entries 
can  only  be  processed  when  the  corresponding  accept  statement  is  reached.  Thus  many  different 
tasks  could  be  held  up  attempting  to  call  PUT^LINE.  They  are  only  accepted  one  at  a time  in 
accordance  with  the  groups  of  calls  of  GET_CHAR.  Again  note  that  the  buffer  may  be  emptied  by 
several  different  tasks  calling  GET_CHAR.  Indeed  several  tasks  could  be  suspended  on  calls  of 
GET_CHAR  until  a task  issues  a call  of  PUT_LINE. 

It  should  be  carefully  observed  that  a task  can  only  be  in  one  queue  at  a time  (and  then  only  in  it 
once).  This  is  because  a task  can  naturally  only  be  calling  one  entry  at  a time. 

This  example  could  therefore  be  used  to  provide  a simple  buffering  mechanism  between  a 
producer  and  consumer  task  thus  (assuming  the  corresponding  tasks  have  baen  initiated) : 

task  CONSUME_CHAR; 
task  PRODUCE_LINE; 

task  body  PRODUCE.LINE  is 
usa  LINE_TO_CHAR; 

MY.LINE  : LINE; 

bagin 

loop 

— fill  MY_LINE  from  somewhere 
PUT_LINE(MY_LINE); 

and  loop; 
end; 

task  body  CONSUME.CHAR  is 
usa  LINE_TO_CHAR; 

MY_CHAR  : CHARACTER; 

bagin 

loop 

GET_CHAR(MY_CHAR); 

--  dispose  of  MY_CHAR 

and  loop; 
and; 

In  the  task  LINE_TO_CHAR  there  is  only  one  accept  statement  corresponding  to  each  entry.  This 
need  not  necessarily  be  the  case  as  later  examples  will  show.  Moreover  if  there  are  several  accept 
statements  corresponding  to  one  entry  then  the  bodies  of  the  statements  may  differ.  We  see  here 
a sharp  distinction  between  entries  and  procedures.  All  calls  of  a procedure  execute  the  same 
body  whereas  calls  of  entries  need  not.  Entries  are  closely  akin  to  coroutines  in  this  respect. 

As  general  programming  practice  the  body  of  the  entry  between  do  and  and  should  not  contain 
unnecessary  statements  otherwise  the  calling  task  will  be  needlessly  held  up.  As  a consequence, 
it  will  often  be  the  case  that  the  end  will  follow  the  last  statement  which  needs  to  access  an  entry 
parameter. 

An  accept  statement  may  have  no  do  ...  end  part.  This  will  usually,  but  not  necessarily,  be  the  case 
when  the  entry  has  no  parameters. 
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For  example  the  following  task  implements  a binary  semaphore  for  protecting  critical  sections: 

task  SEMAPHORE  is 
entry  P; 
entry  V; 
end; 


task  body  SEMAPHORE  is 
begin 
loop 

eccept  P; 
accept  V; 
end  loop; 
end; 

A critical  section  is  then  bracketed  thus 
P; 

— critical  section 
V; 

In  this  case  the  rendezvous  merely  provides  synchronization  and  no  data  is  transferred. 

An  entry  can  be  declared  in  a task  specification  or  in  the  outermost  declarative  part  of  a task  body 
and  is  srid  to  be  owned  by  the  task.  In  the  simple  examples  we  have  met  so  far,  the  entries  have 
all  been  declared  in  the  visible  part.  The  task  READER_WRITER  in  the  next  section  illustrates  the 
use  of  a local  entry. 

There  are  constraints  on  the  position  of  an  accept  statement  to  ensure  that  it  is  only  executed  by 
the  task  owning  the  corresponding  entry.  Firstly  an  accept  statement  may  only  be  in  the  body  of 
the  task  and  not  in  an  inner  task.  Secondly  if  an  accept  statement  is  in  a procedure  then  that 
procedure  may  not  be  called  directly,  or  indirectly,  by  a visible  procedure  or  by  the  body  of  an  inner 
task. 

If  an  entry  is  renamed,  it  is  renamed  as  a procedure.  This  preserves  the  uniform  user  interface.  A 
minor  distinction  between  entries  and  procedures  is  that  it  is  not  possible  *o  have  an  entry  func- 
tion. Finally  it  should  be  remarked  that  it  is  possible  to  have  families  of  entries.  These  are  discussed 
in  11.2.8. 


1 1 .2.5  The  Select  Statemen' 


The  accept  statement  enables  ? task  to  wait  for  some  event  to  happen  and  the  happening  of  the 
event  is  in  our  notation  indicatec  ’•>•/  the  calling  of  the  corresponding  entry.  To  wait  for  several 
events  all  to  have  happened  merely  raquires  a sequence  of  accept  statements.  To  wait  for  one 
only  of  several  alternatives  is  not  easy  and  for  this  purpose  we  introduce  the  select  statement.  As 
will  become  evident,  the  select  statement  has  exceptional  expressive  power. 

The  select  statement  has  some  analogy  with  the  case  statement  and  in  ,'ts  simplest  form  allows 
one  of  several  alternative  accept  statements  to  be  obeyed. 
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As  an  example  suppose  we  wish  a variable  to  be  accessible  to  many  task  but  nevertheless  wish  to 
prevent  more  than  one  task  from  accessing  it  at  the  same  time.  Moreover  suppose  we  wish  to 
provide  facilities  to  read  the  variable  and  to  write  a new  value  to  it.  The  followihg  task  provides  the 
entries  READ  and  WRITE  for  this. 

task  PROTECTED_VARIABLE  is 
entry  READ  (V  . out  ELEM); 
entry  WRITE  (E  : in  ELEM); 

end; 

task  body  PROTECTED_VARIABLE  is 
VARIABLE  : ELEM; 

begin 
loop 
iploct 

accept  READ  (V  : out  ELEM)  do 
V ;=  VARIABLE: 
end; 
or 

accept  WRITE (E  ; in  ELEM)  do 
VARIABLE  :=  E; 

end; 

end  select; 
end  loop; 

end  PROTECTED_VARIABLE; 

A call  of  READ  copies  the  value  of  the  variable  into  its  parameter  V.  A call  of  WRITE  copies  the 
expression  E passed  as  parameter  into  the  variable. 

The  select  statement  allows  the  task  to  accept  either  READ  or  WRITE.  On  entry  to  the  select 
statement  if  neither  a READ  nor  a WRITE  has  been  called,  the  task  waits  for  the  first  of  either  and 
then  obeys  the  appropriate  accept  statement.  If  one  has  already  been  called  then  that  call  is 
immediately  accepted.  If  however  both  entries  have  already  been  called  (obviously  by  two  or  more 
other  tasks)  then  one  of  the  alternatives  is  chosen  in  a completely  random  manner. 

In  the  more  general  case  each  alternative  may  include  a guarding  condition  following  whan.  These 
conditions  are  all  evaluated  at  the  beginning  of  the  select  statement  and  only  those  alternatives 
whose  guards  are  true  are  considered  in  the  subsequent  selection.  An  absent  guard  is  of  course 
considered  to  be  true.  If  all  guards  are  false  so  that  no  alterna'tive  can  be  considered,  then  it  is  an 
error  (unless  there  is  an  else  part  as  described  later  in  this  section)  and  the  SELECT_ERROR  excep- 
tion is  raised.  An  alternative  whose  guard  is  true  (or  absent)  is  said  to  be  open.  If  the  guard  is  false 
it  is  dosed. 

It  should  also  be  noted  that  each  alternative  may  also  include  further  statements  following  the 
rendezvous  body  of  the  accept.  These  additional  statements  are  executed  in  the  normal  way  after 
the  rendezvous  has  been  completed.  I 

The  following  example  of  a bounded  buffer  illustrates  the  use  of  guards. 


task  BUFFERING  ia 

entry  READ  (V  : out  ITEM); 
entry  WRITE  (E  : in  ITEM); 
end; 

taak  body  BUFFERING  ia 

SIZE  : conatant  INTEGER  :=  10; 

BUFFER  : array  (1  ..  SIZE)  of  ITEM; 

INX.  OUTX  : INTEGER  ran  go  1 ..  SIZE  :=  1; 

COUNT  ; INTEGER  rang#  0 ..  SIZE  ;=  0; 
begin 
loop 
aa.dct 

whan  COUNT  < SIZE  => 

accapt  WRITE  (E  ; in  ITEM)  do 
BUFFER(INX)  :=  E; 

and; 

INX  INX  mod  SIZE  + 1; 

COUNT  :=  COUNT  + 1; 

or 

whan  COUNT  > 0 => 

accapt  READ  (V  : out  ITEM)  do 
V :=  BUFFER(OUTX); 

and; 

OUTX  :=  OUTX  mod  SIZE  + 1; 

COUNT  :=  COUNT  - 1; 

and  aaiact 
and  loop; 
and  BUFFERING: 

The  variables  INX  and  OUTX  index  the  ends  of  the  currently  used  part  of  the  buffer  and  COUNT 
indicates  how  many  items  are  in  the  buffer.  Note  how  obvious  the  guards  are.  A READ  can  only 
be  accepted  when  the  buffer  is  not  empty  and  a WRITE  can  only  be  accepted  when  the  buffer  is 
not  full.  The  reader  is  invited  to  compare  the  readability  of  the  solution  presented  here  with  the 
example  written  in  other  languages  in  section  11.4.2. 

It  should  be  noted  that  the  updating  of  the  values  of  INX,  OUTX  and  COUNT  is  not  done  within  the 
rendezvous.  This  allows  the  calling  t8sk  to  continue  as  soon  as  possible. 

The  next  example  shows  the  use  of  local  entries.  It  is  an  extension  of  the  task  PROTECTED_- 
VARIABLE  described  above  and  allows  several  tasks  to  READ  simultaneously  but  only  one  to 
WRITE  when  no  tasks  are  reading. 


teak  REAOER_WRITER  Is 

prooedura  READ(V  : out  ELEM); 
entry  WRITE(E  : in  ELEM); 


'wit  body  READER_WRITER  la 
VARIABLE:  ELEM; 

READERS  : INTEGER  :«  0; 
entry  START_READ; 
entry  STOP-READ; 

•woeeduce  READIV  : out  ELEM)  la 

***  START-READ; 

V VARIABLE; 

STOP-READ; 

and; 

btgin 

aoeopt  WRITEIE  : In  ELEM)  do 
VARIABLE  E; 


•coopt  START-READ; 

READERS  :«  READERS  + 1; 
or 

aooopt  STOP-READ; 

READERS  READERS  - 1; 
or 

whon  READERS  = 0 -> 

aooopt  WRITEIE  : In  ELEM)  do 
VARIABLE  E; 

and; 

a 

•iHl  MliCi, 

and  loop; 

and  READER-WRITER; 

In  this  example  READ  is  s procedure  end  not  an  entry.  However  since  entries  are  called  in  the 
same  way  as  procedures  the  effective  Interface  from  the  point  of  view  of  the  caller  remains 
unchanged.  Of  course  the  compiled  calling  code  may  be  different  but  this  need  not  concern  the 
user. 

This  example  also  illustrates  the  use  of  more  than  one  accept  atatement  corresponding  to  the  entry 
WRITE  (in  this  particular  example  the  bodiea  are  the  aame  but  this  need  not  be  the  case).  It  shows 
that  a task  can  be  viewed  as  a sort  of  coroutine  where  entry  calls  can  achieve  different  actions 
depending  on  the  current  point  of  execution  of  the  task. 

We  now  consider  a further  elaboration  of  this  example  which  gives  a better  distribution  of  priority 
between  readers  and  writers.  Normally  writers  have  priority  over  readers  and  a new  reader  should 
not  be  permitted  to  start  if  there  Is  a writer  waiting. 
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However  all  waiting  readers  at  the  end  of  a write  should  have  priority  over  the  next  writer.  In  order 
to  program  this  strategy  we  use  the  attribute  E'COUNT  of  an  entry  E which  denotes  the  number  of 
tasks  waiting  in  the  queue  for  the  entry.  The  use  of  this  attribute  requires  some  care  as  explained 
below.  We  illustrate  this  point  by  means  of  two  different  formulations  of  this  problem.  The  visible 
part  of  READER-WRITER  remains  unchanged  In  the  first  formulation  (not  the  better  one),  the 
declaration 

N : INTEGER  :=  0; 

is  added  to  the  declarat.ve  part  of  the  body  and  the  statement  part  now  becomes  as  follows: 

begin 

accept  WRITEIE  : in  ELEM)  do 
VARIABLE  :=  E; 

N :«  START-READCOUNT. 

end: 

loop 

ifliot 

when  WRITE  COUNT  * 0 or  N > 0 »> 
accept  START-READ; 

READERS  :«  READERS  + 1: 

If  N > 0 then 

N :*  N - 1; 

end  If: 
or 

accept  STOP-READ; 

READERS  READERS  - 1; 
or 

when  READERS  = 0 and  N = 0 -> 
accept  WRITEIE  : in  ELEM)  do 
VARIABLE  :=  E; 

N :-  START-RF.AD  COUNT; 
and; 

and  select: 
end  loop: 
end; 

In  this  formulation,  N is  the  number  of  readers  still  waiting  of  those  who  were  waiting  when  the 
previous  write  finished. 

The  ftfo  queue  discipline  is  necessary  for  the  correct  working  of  this  example.  At  the  end  of  each 
write,  the  number  of  readers  waiting  is  noted  in  N.  A new  reader  is  only  accepted  when  there  are 
no  writers  waiting  unless  some  of  the  old  readers  are  still  to  be  served;  hence  the  test  of  N in  the 
guard  of  aooept  START_READ  and  the  decrement  of  N in  the  body  of  START_READ.  Similarly, 
the  guard  of  aooept  WRITE  ensures  that  a new  writer  Is  only  served  if  there  are  no  current  reeders 
or  old  readers  still  waiting. 

The  above  formulation  should  be  treated  with  caution.  For  consider  what  happens  If  one  of  the 
waiting  readers  is  aborted  while  in  the  queue  on  the  entry  START.READ,  and  after  the  value  of 
START_READ'COUNT  has  been  assigned  to  N.  The  value  of  N will  then  become  Inconsistent  and 
the  next  writer  will  be  further  delayed  until  a new  reader  arrives. 


This  illustrates  a general  danger  with  using  the  COUNT  attribute  in  guards,  since  any  task  that  has 
issued  an  entry  call  can  receive  an  axception  between  the  evaluation  of  COUNT  and  the  execution 
of  an  accept  statement  based  on  the  value  of  the  COUNT.  Note  however  that  a guard  of  the  form 
E'COUNT  = 0 is  never  dangerous.  No  task  was  in  the  queue  and  so  none  can  disappear. 

We  will  now  reformulate  the  above  example  avoiding  the  dangerous  use  of  COUNT  by  introducing 
the  else  part  of  the  select  statement.  A select  statement  may  contain  an  else  part  following  the 
various  possibly  guarded  alternatives.  The  else  part  cannot  be  guarded.  If  all  guards  are  false,  or 
an  immediate  rendezvous  is  not  possible,  then  the  else  part  is  obeyed.  If  there  is  an  else  part  then 
o SELECT_ERROR  cannot  arise. 


In  the  reformulated  example,  N is  no  longer  required  and  the  main  loop  now  becomes  as  follows: 


when  WRITE'COUNT  = 0 =>  --  this  is  safe 

eeeept  START.READ; 

READERS  :=  READERS  + 1; 


accept  STOP.READ; 
READERS  :=  READERS  - 1; 


when  READERS  = 0 => 

accept  WRITHE  : in  ELEM)  do 
VARIABLE  :=  E; 


accept  START.READ; 
READERS  :=  READERS  + 1; 


end  loop: 


and  loop; 

After  accepting  a WRITE  the  task  loops  accepting  as  many  START_READs  as  can  immediately  be 
processed.  Of  course  the  behavior  is  marginally  different  but  the  general  objective  is  satisfied.  The 
loop  ought  also  to  follow  the  initial  WRITE  and  so  could  conveniently  be  placed  in  a procedure. 

There  are  constraints  on  the  position  of  a select  statement  identical  to  those  of  the  accept  state- 
ment. These  are  of  course  necessarily  imposed  by  the  accept  statements  in  the  alternatives. 
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It  is  finally  worth  noting  that  the  entries  in  the  various  alternatives  need  not  be  distinct  (although 
they  usually  will).  If  two  or  more  prove  to  be  the  same  then  the  usual  rule  of  random  selection 
applies. 


11.2.6  The  Delay  Statement 


The  delay  statement  postpones  the  execution  of  the  task  for  at  least  the  specified  time  interval 
delay  2 O.SECONDS 

The  expression  following  delay  represents  the  number  of  basic  time  units  of  the  real  time  clock  (on 
the  obiect  machine)  tor  which  the  task  is  to  be  suspended.  This  expression  will  be  of  the 
predefined  floating  point  type  TIME.  An  integer  type  is  not  appropriate  since  the  range  of  times  to 
be  accommodated  will  often  exceed  the  range  of  integers  on  many  object  machines.  The 
predefined  constant  SECONDS  is  the  number  of  basic  time  units  in  one  second  and  allows  the 
expression  to  be  written  in  a natural  manner.  The  user  can  of  course  declare  other  appropriate 
constants.  Thus 

MINUTES  constant  TtME  600  • SECONDS: 

It  should  be  realized  that  the  use  of  a floating  point  type  for  delays  does  not  introduce  any 
additional  timing  drift.  The  use  of  a simple  delay  in  a loop  such  as 

loop 

delay  1 O.MINUTES; 

end  loop: 

does  not  cause  the  body  of  the  loop  to  be  executed  every  minute  anyway  because  of  the  time 
taken  to  execute  the  statements  in  the  loop.  Accurate  timing  requires  repeated  reading  of  the  clock 
and  the  use  of  a floating  point  type  need  not  introduce  any  drift 

A delay  statement  may  occur  in  place  of  an  accept  statement  as  the  synchronization  part  of  an 
alternative  of  a select  statement  and  may  have  a guard  in  the  usual  way.  Such  a delay  statement 
may  be  used  to  provide  a time-out  for  the  select  statement.  If  no  rendezvous  has  occurred  within 
thf?  specified  interval  then  the  statement  list  following  the  delay  statement  is  executed.  Of  course 
if  a rendezvous  occurs  before  the  interval  has  expired  then  the  delay  is  cancelled  and  the  select 
statement  is  executed  normally. 

As  an  example  we  can  consider  a task  to  drive  a chain  printer  *f  the  printer  does  not  receive  any 
printing  order  for  1 0 seconds  then  the  chain  has  to  be  stopped.  Once  It  has  stopped  a further  print 
request  will  cause  it  to  restart  but  a 1 second  delay  must  take  place  before  printing  commences. 
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tMh  PRINTER-DRIVER  la 
entry  PRINTIL  LINE): 

and: 

teak  body  PRINTER-DRIVER  la 

CHAIN-GOING  BOOLEAN  FALSE 
BUFFER  : LINE; 


sdoct 

accept  PRINTIL  : LINE)  do 
BUFFER  L; 

and; 

N not  CHAIN. GOING  than 

[ - start  the  chain 

dalay  1 O.SECONDS: 
CHAIN. GOING  TRUE; 

and  N; 

- print  the  line 

°» 

whan  CHAIN-GOING  -> 
(May  10.0.SEC0NDS 
— stop  tha  chain 
CHAIN-GOING  : FALSE: 


Of  course  a select  statement  may  have  several  alternatives  with  a delay  statement  as  the  syn- 
chronization statement.  This  extends  the  general  rule  that  the  entries  in  the  different  alternatives 
need  not  be  distinct.  If  th;»re  are  several  delays  (with  guard  true)  then  the  one  with  the  shortest 
delay  is  chosen. 

A select  statement  may  not  have  alternatives  commencing  delay  as  well  as  an  else  part;  the  else 
part  would  always  take  precedence  anyway.  Moreover,  at  least  one  alternative  must  have  an 
accept  statement.  This  regularizes  the  constraint  on  the  position  of  the  select  statement. 


11.2.7  Interrupts 


Hardware  interrupts  are  simply  handled  by  interpreting  them  as  an  external  entry  call.  A represen- 
tation specification  is  used  to  link  the  entry  to  the  interrupt  thus 

for  IO-OONE  use  at  4. 

I he  value  following  at  is  interpreted  in  a machine  dependent  manner.  For  example  it  could  he  a 
physical  address,  an  index  into  a table  of  records,  or  a binary  ni  mber  representing  encoded  infor- 
mation.  i 

9 

t 

The  interrupt  is  processed  when  the  task  owning  the  entry  performs  a rendezvous  by  using  a cor- 
responding accept  statement  * " 
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— i mi  *, 


accept  IO_DONE, 

Multiple  interrupts  are  queued  as  any  other  entry  call  is  queued  although  there  may  be  a system 
defined  limit  to  the  number  of  possible  pending  interrupts  on  a given  entry. 

The  mechanism  of  masking  interrupts  is  not  visible  to  the  user  but  is  handled  by  the  implementing 
software  which  connects  the  interrupts  to  the  entry  call.  This  approach  enables  the  language  to  be 
reasonably  machine  independent  in  an  otherwise  awkward  area. 

An  interrupt  may  return  control  information  via  an  in  parameter  of  the  entry.  Clearly  an  entry 
associated  with  an  interrupt  cannot  have  out  or  in  out  parameters. 


11.2.8  Families  of  Tasks  and  Entries 


The  possibility  of  having  families  of  tasks  and  entries  has  been  mentioned  above.  A family  is  con- 
ceptually similar  to  an  array  but  different  terminology  is  used  in  order  to  maintain  a clear  distinc- 
tion between  program  concepts  such  as  tasks  and  data  concepts  such  as  integers.  Furthermore 
the  allocation  strategy  for  families  of  tasks  can  be  different  from  that  of  an  array  (see  1 1 .4.6). 

A natural  use  of  a family  of  tasks  occurs  when  there  are  several  copies  of  a piece  of  physical  equip- 
ment and  a distinct  but  similar  task  is  required  to  drive  each  one.  Thus  suppose  we  have  10  line 
printers  and  wish  to  drive  each  one  by  a distinct  task  such  as  PRINTER_DRIVER  of  section  1 1 .2.6. 
The  specification  part  would  then  become 

tart  PRINTER.DRIVER  (1  ..  10)  is 
entry  PRINTIL  : LINE); 

end; 

The  task  body  would  remain  the  same.  A member  would  be  designated  by  appending  a subscript 
in  a manner  analogous  to  an  array  component.  "rhus  the  sixth  member  would  be  initiated  by 

initiate  PRINTER_DRIVER(6); 

Alternatively  the  whole  family  would  be  initiated  by 

initiate  PRINTER_DRIVER(  1 ..  10); 

In  order  to  call  an  entry,  the  member  of  the  family  has  to  be  indicated  in  full: 
PRINTER_DRIVER(I).PRINT(MY_LINE); 
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It  is  often  convenient  to  rename  an  entry  in  such  circumstances  so  that  calls  are  abbreviated  Thus 


procedure  PRINT-6  renames  PRINTER_DRIVER(6)  PRINT 

A procedure  in  the  visible  part  is  called  in  a similar  manner.  Types,  constants  and  exceptions 
however  belong  to  the  family  as  a whole  and  are  denoted  by  just  using  the  family  name  and  not 
the  member  name. 

W'thin  the  text  of  a family  it  is  sometimes  necessary  to  refer  to  the  index  of  the  current  member 
This  can  be  done  by  the  use  of  the  INDEX  attribute  Thus  in  the  above  case 

PRINTER-DRIVER  INDEX 

would  give  the  index  of  the  particular  driver.  It  could,  for  example,  be  the  case  that  the  printers  are 
controlled  by  a multiplexer.  The  printers  could  communicate  with  the  multiplexer  by  calling  its 
entries  and  passing  their  index  as  a parameter  so  that  the  multiplexer  knows  which  printer  it  is 
dealing  with  at  any  time. 

A family  of  tasks  is  an  appropriate  technique  to  use  when  the  individual  members  correspond  to 
physically  jutonomous  pieces  of  equipment  We  will  now  introduce  families  of  entries  and 
illustrate  their  use  with  a problem  in  which  the  individual  physical  items  are  not  completely 
independent. 

A family  of  entries  is  declared  by  adding  a range  specification  to  the  entry  name  in  the  declaration. 
Thus 

entry  TRANSFER!  1 ..  200ND  : DATA); 
declares  a family  of  200  entries  each  of  which  has  the  parameter  D. 

A particular  entry  is  called  by  the  use  of  a subscript  as  expected 
TRANSFER(l)(DATA_VAlUE); 

In  the  corresponding  accept  statement,  the  particular  member  has  to  be  indicated  by  appending  an 
actual  index  to  '.he  family  name.  It  is  then  followed  by  the  formal  parameter  list,  if  any,  in  the  usual 
way 

accept  TRANSFERIIHD  : DATA)  do  ...  end  TRANSFER 

Our  example  is  that  of  scheduling  a queue  of  requests  for  data  transfers  to  or  from  a moving  head 
disk.  In  order  to  minimize  head  movement  the  requests  are  grouped  into  separate  queues  for  each 
track  and  all  the  requests  for  a particular  track  are  serviced  together.  It  would  be  possible  to  con- 
sider each  track  as  a separate  physical  entity  demanding  its  own  task  We  would  then  use  a family 
of  tasks.  However,  the  tracks  are  not  independent.  The  disk  can  only  be  serving  one  track  at  a time 
and  so  the  parallelism  obtained  by  using  many  tasks  is  not  necessary  Instead  the  transfers  are 
handled  by  a single  slave  task  with  a family  of  entries.  There  is  an  entry  for  each  track  so  that  the 
queues  are  independent.  A separate  task  controls  the  arm  movement  and  the  choice  of  track  for 
the  slave  task. 
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task  DISK  ..HEAD.SCHEDUIER  it 

tvpo  TRACK  is  new  INTEGER  range  1 , 200. 
typs  DATA  is  other  parameters  of  transfer 

procedure  TRANSMIT(TN  TRACK;  D DATAI: 


task  body  DISK_HEAD_SCHEDULER  is 
type  DIRECTION  is  (UP  DOWN); 

INVERSE  oonatant  array  (UP  DOWN)  of  DIRECTION  :« 

(UP  ->  DOWN.  DOWN  »>  UP): 

STEP  conetant  array  (UP  DOWN)  o(  INTEGER  ran«a  1 1 •= 

(UP  •=>  V DOWN  =>  -1) 


WAITING  array  (TRACK  FIRST  TRACK  LAST)  of  INTEGER 
COUNT  array  (UP  DOWN)  of  INTEGER  - (UP  DOWN 
MOVE  DIRECTION  DOWN 


(TRACK  FIRST  ..  TRACK  LAST  =>  0) 
0). 


ARM_  POSITION  : TRACK  1 


entry  SIGNJNIT  TRACK); 

entry  FINO.  TRACKIREQUESTS  out  INTEGER  TRACK_NO  out  TRACK); 


task  TRACK  MANAGER  is 

entry  TRANSFERITRACK  FIRST  . TRACK  LASTKD  : DATA) 

end 


procedure  TRANSMITITN  TRACK;  D DATA)  ie 

k. 1 — 

SIGNJN(TN) 

TRACK  .MANAGER  TRANSFER(TNKD): 


task  body  TRACK_MANAGER  is 
NO.OF  REQUESTS  INTEGER 
CURRENT_TRACK  TRACK: 


FIND_TRACK(NO_OF. REQUESTS  CURRENT  TRACK) 
while  NO_OF_REQUESTS  > 0 loop 

accept  TRANSFER(CURRENT_TRACK)(D  : DATA)  do 
- do  actual  I/O 

NO-OF..REQUESTS  NO.OF.REQUESTS  1 • 
and  TRANSFER; 

and  loop 
and  loop; 

end  TRACK_MANAGER; 
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ARM_POSITION  ARM_F  3ITI0N  ♦ STEP(MOVE): 

white  WAITING(ARM_POS'TION)  - 0 loop 

ARM_POSITION  :=  ARM_POSITION  + STEP(MOVE): 

•nd  loop; 

COUNT(MOVE)  :=  COUNT(MOVE)  - WAITING(ARM_POSITION! 

REQUESTS  WAmNG(ARM_POSITION>: 

TRACK_NO  :=  ARM.POSITION: 

WAITING(ARM_POSITION)  ; 0 

•nd  FIND_TRACK; 
or 

•ccopt  SIGf  IN(T  : TRACK)  do 
If  T < ARM_POSITlON  tfwn 

COUNT(DOWN)  :=  COUNTDOWN'  ♦ 1; 

MT  > ARM_POSITION  tfwn 
COUNT(UP)  :=  COUNT(UP)  + 1; 

•tea 

COUNT(INVERSEIMOVE))  COUNT(INVERSEiMOVEI)  ♦ 1; 

•nd  If; 

WAITING(T)  :=  WAITING(T)  -t-  1: 

•nd  SIGN_IN; 

•nd  Mtoct; 

•nd  loop: 

•nd  OISK_HEAD_SCHEDULER; 

The  user  indicates  his  requests  by  calling  the  procedure  TRANSMIT  This  in  turn  calls  the  entry 
SIGN.IN  in  the  main  task  which  records  the  request  and  then  the  user  waits  on  the  call  of 
TRANSFER  until  the  slave  task  TRACK_MANAGER  is  ready  to  perform  transfers  on  the  track  con- 
cerned. 

The  slave  task  TRACK_MANAGER  calls  the  entry  FIND_TRACK  in  order  to  determine  which  track 
should  be  handled  next.  DISK_HEAD_SCHEDULER  only  honors  the  call  when  there  are  requests 
outstanding  (C0UNT(UP)  + C0UNT(D0WN)>0).  If  there  are  requests  outstanding,  an  extended 
rendezvous  occurs  during  which  the  arm  is  moved  and  the  data  transferred  to  TRACK_MANAGER. 

Note  the  accept  statement  within  TRACK_MANAGER  which  references  the  member  CUR- 
RENT_TRACK  of  the  family  TRANSFER  and  so  finally  deals  with  the  user  who  has  been  waiting  in 
TRANSMIT. 

It  should  be  pointed  nut  that  the  example  given  is  purely  illustrative.  No  genuine  disk  head 
scheduler  would  need  to  be  so  heavily  engineered.  A perfectly  adequate  solution  is  to  allow  only 
two  calls  to  track  manager  at  a time  and  to  sort  these  into  the  more  efficient  order.  If  a disk  queue 
frequently  exceeds  two  items  then  the  system  is  grossly  overloaded  anyway  and  elaborate 
scheduling  is  unlikely  to  help. 
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11.2.9  Generic  Tasks 


The  final  concept  to  be  described  is  that  of  a generic  task.  A full  description  of  generics  is  given  in 
chapter  12  of  the  Reference  Manual  and  we  merely  describe  here  a simple  example  which 
illustrates  the  need  for  and  use  of  generic  tasks. 

We  saw  in  section  1 1 .2.4  how  a simple  task  could  implement  a binary  semaphore  for  protecting  a 
critical  region.  The  main  shortcoming  of  the  example  was  that  it  only  implemented  a single 
semaphore  and  did  not  provide  a mechanism  whereby  the  user  could  declare  as  many  semaphores 
as  he  wished.  By  making  the  task  generic  this  difficulty  can  w«j  overcome  and  we  illustrate  it  by  the 
allied  example  of  a signal. 

A simple  signal  has  two  operations,  SEND  and  WAIT.  One  task  may  SEND  a signal  and  another 
may  WAIT  for  it.  When  a signal  is  sent  only  one  waiting  task  is  released.  A signal  is  remembered 
until  a task  waits  but  repeated  sends  are  ignored.  A solution  is  as  follows: 

generic  task  SIGNAL  is 
entry  SEND; 
entry  WAIT; 
end  SIGNAL; 

task  body  SIGNAL  is 

HAS_OCCURRED  : BOOLEAN  :=  FALSE; 

begin 

loop 

select 

accept  SEND; 

HAS_OCCURRED  :=  TRUE; 

or 

when  HAS_OCCURRED  => 
accept  WAIT; 

HAS.OCCURRED  :=  FALSE; 

end  select; 
end  loop; 
end; 

Within  the  user  a particular  signal  is  declared  thus: 

task  MY.SIGNAL  is  new  SIGNAL; 

The  calls  of  WAIT  and  SEND  then  appear  as 

MY.SIGNALWAIT; 

MY_SIGNAL.SEND; 

Signals  and  semaphores  are  predefined  generic  tasks.  This  should  enable  an  implementation  to 
make  optimal  use  of  any  synchronization  facilities  provided  by  the  machine  or  underlying  system. 
For  example,  if  semaphores  are  supplied  by  a given  hardware,  calls  to  the  P and  V operations  can 
be  mapped  directly  on  the  corresponding  hardware  primitives.  In  such  a case  the  package  body 
should  only  be  considered  as  a semantic  description  of  the  corresponding  construct. 


11-20 


remembered  and  a task  must  wait  for  a later  occurrence  of  the  signal.  A signal  sent  when  no  one 
is  waiting  is  completely  lost.  A solution  is 

task  body  P ASSING_SIGNAL  is 
begin 
loop 

accept  SEND. 

•elect 

accept  WAIT; 

else 

null; 

end  select; 
end  loop: 

end  PASSING_SIGNAL: 


11.2.10  Scheduling 


The  key  to  designing  parallel  tasks  in  the  Green  language  lies  in  the  realization  that  queues  are 
associated  with  entries  and  only  entries  and  that  such  queues  are  handled  in  a strictly  first  in  first 
out  manner.  The  example  of  the  DISK_HEAD_SCHEDULER  showed  how  a family  of  entries  could 
be  used  to  fragment  a queue  into  subqueues.  The  fifo  nature  of  the  entry  queue  might  be  thought 
to  be  a severe  constraint  in  cases  where  some  requests  may  be  of  high  priority  and  also  in  cases 
where  later  similar  requests  could  be  satisfied  even  though  earlier  ones  had  to  wait. 

The  handling  of  requests  with  priorities  is  easily  achieved  by  the  use  of  separate  entries  for  each 
level.  A family  can  conveniently  be  used  for  that  purpose.  The  following  example  illustrates  an 
approach  suitable  for  a small  number  of  levels. 

task  CONTROL  is 

type  LEVEL  is  (URGENT,  MEDIUM.  LOW); 

entry  REQUEST  (LEVELFIRST  ..  LEVEL'LASTXD  : DATA); 

and; 

task  body  CONTROL  is 

9#l#Ct 

accept  REQUESTIURGENTXD  : DATA)  do 

and; 

or  whan  (REQUEST(URGENT)  COUNT  = 0)  •=> 
accept  REQUESTIMEDIUMXD  ; DATA)  do 

and; 

or  whan  (REQUEST(URGENT)'COUNT  = 0)  and  (REQUEST(MEDIUM)’COUNT  = 0)  => 
accept  REQUEST(L0W)(D  : DATA)  do 

and; 

and  select 

end  CONTROL; 

The  use  of  the  COUNT  attribute  in  the  above  example  is  quite  safe. 
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For  a larger  number  of  levels,  a different  approach  may  be  more  appropriate  as  is  illustrated  below: 


task  CONTROL  is 

subtype  LEVEL  is  INTEGER  range  1 ..  50; 
procedure  REQUEST  <L  LEVEL:  0 : DATA); 

end 


task  body  CONTROL  is 

entry  SIGNJN  (L  : LEVEL); 

entry  PERFORM  ILEVEL'FIRST  ..  LEVEL'LASTMD  . DATA); 

PENDING  : array  (LEVEL  FIRST  ..LEVEL  LAST)  of  INTEGER  := 

ILEVEL'FIRST  LEVEL'LAST  =>  0); 

TOTAL  : INTEGER  :=  0; 


procedure  REQUESTS  : LEVEL;  D : DATA)  is 

begin 

SIGN  JN(L); 

PERFORM(L)ID); 

end 


begin 

loop 

if  TOTAL  = 0 then 


no  request  to  be  served:  wait  if  necessary 
accept  SIGN JN(L  . LEVEL)  do 
PENDINGIL)  :=  PENDING(L)  + 1; 

TOTAL  :=  1; 


end  SIGN_IN; 
end  if; 

loop  — accept  any  pending  SIGN_IN  call  without  waiting 

select 

accept  SIGNJNIL  : LEVEL)  do 
PENDINGIL)  :=  PENDING(L)  + 1; 

TOTAL  :=  TOTAL  4-  1; 
end  SIGNJN: 

else 

exit; 

end  select; 
end  loop; 


for  I in  reverse  LEVEL  FIRST  LEVEL  LAST  loop 
if  PENDING(I)  > 0 then 

accept  PERFORMIDID  : DATA)  do 

satisfy  the  request  of  highest  level 

end; 

PCNDING(I)  : PENDING(I)  1; 

TOTAL  :=  TOTAL  - 1; 


exit 
end  if; 


restart  main  loop  in  order  to  accept  new  requests 


end  loop 
and  loop; 

end  CONTROL; 


11-22 


In  order  to  service  a request,  a call  to  SIGN_IN  must  first  be  accepted  and  its  occurrence  recorded 
in  the  global  counter  TOTAL,  and  the  appropriate  PENDING  counter  In  a second  step  the 
appropriate  entry  of  the  family  PERFORM  must  be  accepted.  CONTROL  proceeds  by 

• waiting  for  the  first  SIGN_IN  if-  all  previous  requests  have  been  serviced. 

• accepting  all  pending  calls  to  SIGN_IN, 

• executing  the  request  with  the  highest  priority: 

• going  back  to  the  beginning  of  the  loop  to  take  care  of  any  call  to  SIGNJN  that  has  arrived  in 
the  meantime. 

We  will  now  illustrate  a very  general  mechanism  which  in  effect  allows  the  items  in  a queue  on  a 
simple  entry  to  be  processed  in  an  arbitrary  order  The  example  is  of  a controller  for  the  alia  ation 
of  groups  of  items  from  a set  of  resources 

task  MULTI_RESOURCE_CONTROL  is 

type  RESOURCE  is  (A.  B,  C,  D.  E,  F.  G,  H.  I,  J K): 
typa  RESOURCE_SET  is  array  (A  . K)  of  BOOLEAN; 
procedure  RESERVE(GROUP  : RESOURCE_SET); 
entry  RELEASE(GROUP  : RESOURCE_SET): 
end: 

task  body  MULTI_RESOURCE_CONTROL  is 

EMPTY  : constant  RESOURCE_SET  :=  (A  K =>  FALSE); 

USED  : RESOURCE_SET  :=  EMPTY, 

entry  FIRST  (ASKED  : RESOURCE_SET,  OK  : out  BOOLEAN)- 

entry  AGAIN  (ASKED  : RESOURCE_SET:  OK  : out  BOOLEAN): 

procedure  TRY  (ASKED  : RESOURCG_SET.  OK  : out  BOOLEAN), 

procedure  RESERVE  (GROUP  : RESOURCE_SET)  is 
POSSIBLE  : BOOLEAN: 

begin 

FIRST(GROUP.  POSSIBLE); 

while  not  POSSIBLE  loop  — if  at  first  you  don't  succeed  try  again 
AGAIN(G  ROUP.  POSSIBLE); 

end  loop: 
end; 

procedure  TRY(ASKED  : RESOURCE_SET;  OK  : out  BOOLEAN)  is 

begin 

if  (USED  and  ASKED)  = EMPTY  than 
USED  :=  USED  or  ASKED; 

OK  :=  TRUE;  — allocation  successful 


OK  :=  FALSE;  — not  possible,  try  again  later 

and  H: 
and: 


begin  - MULTLRESOURCE_CONTROL 

loop 

select 

accept  FIRSTIASKED  : RESOURCE_SET;  OK  : out  BOOLEAN)  do 
TRY(ASKED.OK); 

end; 

or 

accept  RELEASEIGROUP  : RESOURCE_SET)  do 
USED  :=  USED  and  not  GROUP; 

end; 

for  I in  1 ..  AGAIN'COUNT  loop 
select 

accept  AGAINIASKED  : RESOURCE_SET:  OK  : out  BOOLEAN)  do 
TRY(ASKED.OK); 


else 

exit; 

end  select; 
end  loop; 
end  select; 
end  loop; 

end  MULTI_RESOURCE_CONTROL; 

The  user  requests  and  obtains  an  arbitrary  group  of  resources  by  calling  the  procedure  RESERVE 
and  returns  resources  by  calling  the  entry  RELEASE.  The  procedure  RESERVE  makes  an 
immediate  attempt  to  acquire  the  resources  by  calling  the  entry  FIRST.  If  they  are  not  all  available, 
OK  is  returned  false  and  the  request  is  queued  by  calling  AGAIN.  It  should  be  noted  that  FIRST  is 
always  honored  promptly  (except  when  the  controller  is  busy  with  RELEASE)  whereas  AGAIN  is 
only  considered  when  a RELEASE  occurs.  Thus  all  requests  which  cannot  be  satisfied  immediately 
are  placed  on  the  AGAIN  queue.  It  is  important  that  these  requests  are  not  serviced  on  a FIFO 
basis  but  that  when  some  resources  are  released  the  requests  in  the  queue  that  can  be  fully 
satisfied  should  be  honored.  The  technique  is  to  scan  the  queue  by  doing  a rendezvous  with 
AGAIN  and  to  allow  each  user  (in  RESERVE)  to  place  itself  back  on  the  queue  if  it  cannot  get  the 
resources  it  requires.  In  order  that  each  user  should  have  only  one  retry  the  loop  is  controlled  by 
AGAIN  COUNT  and  it  is  important  that  AGAIN'COUNT  is  only  evaluated  once  at  the  start  of  the 
loop. 


It  should  be  observed  that  users  may  reenter  the  AGAIN  queue  in  a slightly  different  order  because 
of  the  underlying  task  scheduling  strategy.  This  does  not  affect  the  validity  of  the  algorithm.  Note 
also  that  the  accept  statement  is  placed  inside  a select  statement  with  an  else  part  that  terminates 
the  loop.  This  ensures  that  if  a waiting  task  is  aborted  then  the  system  does  not  deadlock. 

The  technique  is  general  but  does  require  the  use  of  a special  protocol  for  calling  FIRST  and 
AGAIN,  although  this  is  hidden  by  maxing  these  entries  local  and  by  enclosing  the  entry  calls  in  the 
procedure  RESERVE.  It  may  appear  surprising  that  the  bodies  of  FIRST  and  AGAIN  are  identical, 
but  FIRST  is  always  necessary  since  the  user  must  be  allowed  the  resources  immediately  if  they 
are  available. 
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11-3  Example:  A Radar  Track  Management  Package 


This  example  shows  the  use  of  packages  and  tasks  to  realize  a complex  real-time  system,  such  as 
radar  surveillance. 

The  TRACK_MANAGEMENT  package  introduces  the  abstract  notion  of  a track.  Several  tracks  can 
coexist.  A current  position  and  a current  speed  vector  in  a two-dimensional  space  are  associated 
with  each  track.  The  position  is  updated  regularly  from  the  value  of  the  speed.  Both  the  position 
and  speed  can  be  modified  externally,  or  examined.  The  restrictions  are  that  those  values  should 
not  be  read  while  they  are  being  changed.  We  thus  have  a classical  reader-writer  problem. 


package  TRACK-MANAGEMENT  is 
type  TRACK-INFO  is 
record 

X,  Y : MILES; 

VX.  VY  : MILES_PER_SECOND; 

T : TIME; 

and  record: 

type  TRACK_ID  Is  private; 

function  CREATE_TRACK  UNIT  : in  TRACKJNFO)  return  TRACK-ID; 

procedure  KILL-TRACK  (T  : in  TRACKJD); 

function  READ-TRACK  (T  ; in  TRACKJD)  return  TRACKJNFO; 

procedure  CHANGE-TRACK  (T  : in  TRACKJD;  D : in  TRACKJNFO); 

NO_MORE_TRACKS,  ILLEGAL-TRACK  ; exception; 
private 

MAX-TRACK  : constant  INTEGER  :=  512; 
subtype  TRACK-RANGE  is  INTEGER  range  0 ..  MAX-TRACK; 
subtype  NAME-TYPE  Is  LONG-INTEGER; 
type  TRACK-ID  is 

INDEX  : TRACK-RANGE; 

UNIQUE-NAME  : NAME-TYPE; 

end  record; 

end  TRACK-MANAGEMENT; 

package  body  TRACK-MANAGEMENT  is 

NULL-TRACK  : constant  TRACK-ID  :=  (0,  0); 

TRACK-NAME  : array  (1  ..  MAX-TRACK)  of  NAME-TYPE  :=  (1  ..  MAX-TRACK  =>  0); 
--  this  is  a table  indicating,  for  each  track,  the  unique  name  currently  assigned  to  it 
LAST-NAME  : NAME-TYPE  :=  0;  - the  last  unique-name  used. 

procedure  CHECK-TRACK  |T  : in  TRACKJD); 

task  TRACK  1 1. MAX-TRACK)  is 

procedure  READ)!  : out  TRACKJNFO); 
entry  CHANGE)!  : in  TRACK-INFO  ); 
entry  INITIALIZE)!  in  TRACK  INFO) 
entry  KILL, 
end  TRACK; 


— global  type 

- global  type 
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task  TRACK_CONTROl  is 

sntry  CREATE_TRACK(IO  : out  TRACKJD); 

•ntry  KILL_TRACK(T  : in  TRACK-ID); 
end  TRACK-CONTROL; 

procedure  CHECK-TRACK  (T  : in  TRACKJD)  is 
— to  ensjre  the  validity  of  a track  value: 

--  * it  has  a positive  index, 

--  * it  has  the  same  unique  name  as  that  known  to  the  system, 
--  * it  is  still  active. 

begin 

if  T.INDEX  = 0 

or  also  TRACK_NAME(T.INDEX)  /=  T.UNIQUE-NAME 
or  else  not  TRACK(T.INDEX)' ACTIVE  then 
raise  ILLEGAL J’RACK; 
end  if; 

end  CHECK-TRACK; 

function  CREATE_TRACK  UNIT  : in  TRACKJNFO)  return  TRACKJD  is 
NEW_TRACK  : TRACKJD; 

begin 

TRACK_CONTROL.CREATE_TRACK(NEW_TRACK); 
initiate  TR AC K ( N E W_TR AC K INDEX); 
TRACK|NEW_TRACK.INDEX).INITIALIZE(INIT); 
return  NEW-TRACK; 
end  CREATE_TRACK; 

procedure  KILL_TRACK(T  ; in  TRACK_ID)  is 

begin 

CHECK-TRACK(T); 

TRACK(T.  INDEX). KILL; 

TRACK_CONTROL.KILL_TRACK(T); 
end  KILL.TRACK; 

function  READ  TRACK  (T  : in  TRACKJD)  return  TRACKJNFO  is 
I : TRACKJNFO; 

begin 

CHECK_TRACK(T); 

TRACK(T.INDEX).READO); 

return  I ; 
exception 

when  TASKING.ERROR  =>  raise  ILLEGAL-TRACK; 
end  READ_TRACK; 

procedure  CHANGE-TRACK  (T  in  TRACKJD;  D : in  TRACK-INFO)  is 
begin 

CHECK-TRACK(T); 

TRACK(T.  INDEX). CHANGE(D); 

exception 

when  TASKING-ERROR  =>  raise  ILLEGAL-TRACK; 
end  CHANGE-TRACK; 


task  body  TRACK  ia 

DATA  : TRACKJNFO; 

READERS  : INTEGER  :=  0; 
entry  START.  READ; 
entry  STOP.READ; 

procedure  READ  (I  ; out  TRACKJNFO)  it 

>fltn 

START.READ: 


I ;=  DATA; 
STOP.READ; 
end  READ; 


procedure  UPDATE.POSITION  is 

NEW.TIME  : TIME  :=  SYSTEM  CLOCK; 

DELTA.TIME  . TIME  ;=  NEW.TIME  DATA.T; 

begin 

DATA.X  :=  DATA  X + DELTA_TIME*DATA  VX; 

DATA.Y  :=  DATA  Y + DELTA_TIME*DATA.VY, 

DATA.T  :=  NEW.TIME; 
end  UPDATE.POSITION: 

begin  - body  of  TRACK; 

eccept  INITIALIZE  (I  ; in  TRACKJNFO)  do 
DATA  :=  I: 
and  INITIALIZE: 

UPOATE.  POSITION; 

loop 

select 

when  CHANGE  COUNT  - 0 and  KILL'COUNT  = 0 => 
accept  START.READ: 

READERS  :=  READERS  + 1; 
or 

when  READERS  > 0 => 
accept  STOP.READ; 

READERS  :=  READERS  - 1; 
or 

when  READERS  = 0 and  KILL'COUNT  = 0 -> 
accept  CHANGE  (I  : in  TRACKJNFO)  do 
DATA  :=  I; 
and  CHANGE; 

UPDATE.POSITION; 
or 

accept  KILL; 
exit; 
or 

delay  0.10*SECONDS; 

UPDATE.POSITION; 

I end  select: 

end  loop; 
end  TRACK; 


I 
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f 


task  body  TRACK_C0NTR01  it 

(unction  FIND  TRACK  return  TRACK_.RANGE  it 

begin 

for  I in  1 ..  MAX_TRACK  loop 
U TRACK_NAME(I)  0 then 
return  I; 
end  if 
end  loop 

raise  NO  MORE  TRACKS; 
end  FIND._TRACK; 

begin  - body  of  TRACK_.CONTROl 

loop 

begin 

select 

accept  CREATE_TRACK(ID  : out  TRACK  ID)  do 
ID  INDEX  FIND_TRACK; 
if  LAST_NAME  <=  NAME.TYPE  LAST  then 
LAST_NAME  :=  1: 

else 

LAST_NAME  :*  LAST_NAME  ♦ 1; 

end  if: 

TRACK_NAME(ID  INDEX)  ;=  LAST_NAME' 

ID  UNIQUE_NAME  LAST_NAME 
end  CREATE.TRACK; 

or 

accept  KILL_TRACK(T  in  TRACKJD)  do 
TRACK_NAME(T)  :=  0 
end  KILL.TRACK; 

end  select 
exception 

when  NO  MORE_TRACKS  > null: 
end; 

end  loop 

end  TRACK_C0NTR01; 

begin  ~ body  of  TRACK_MANAGEMENT 
initiate  TRACK_C0NTR01; 
end  TRACK_MANAGEMENT; 

Tracks  are  manipulated  by  external  agents  through  the  operations  CREATE_TRACK  (to  start  a new 
track,  with  an  initial  value),  READ_TRACK  (to  obtain  the  current  position  on  a track) 
CHANGE_TRACK  (to  modify  the  track  data)  and  KILLTRACK  (to  release  the  track). 

All  tracks  are  independent  This  is  achieved  by  associating  a particular  task  from  a family  to  a new- 
ly created  track.  The  global  management  of  the  pool  of  tasks  is  achieved  by  the  TRACK_- 
CONTROL  task  Note  that  the  TRACK  tasks  act  as  servers,  in  the  sense  that  an  activation  of  one 
task  corresponds  to  one  track,  but  the  same  task  can  represent  different  tracks  in  different  succes- 
sive activations. 

In  order  to  preserve  some  integrity  in  the  way  tracks  are  used  (for  example,  to  ensure  that  a 
reference  to  a track  is  not  that  of  an  obsolete  activation),  a unique  name  is  associated  with  each 
active  track.  This  unique  name  is  a long  integer  which  is  incremented  at  each  track  creation,  and 
recorded  in  the  track  identification.  It  acts  as  a sort  of  password,  in  that,  for  each  active  track  the 
system  keeps  the  unique  name  currently  associated  to  it  in  the  array  TRACK_NAME.  This  one  is 
checked  against  that  contained  in  the  track  identification  Using  a LONGJNTEGER  for  unique 
names  should  guarantee  that  the  same  name  is  not  reused  before  a reasonable  period  of  time. 
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For  each  track,  the  policy  is  that  a track  cannot  br  changed  while  it  is  being  read  that  no  new 
reader  should  be  accepted  if  a change  is  to  be  made,  and  that  termination  should  have  priority  over 
both  reading  and  writing.  One  of  the  consequences  is  that  a track  termination  is  possible  while 
some  readers  are  still  accessing  it  However,  any  reader,  or  any  waiting  writer  will  receive  a 
TASKING_ERROR  exception  when  this  happens 


11.4  Rationale  for  tha  Design  of  the  Tasking  Facilities 

The  section  starts  by  briefly  surveying  some  of  the  more  important  and  older  real  time  primitives 
and  their  shortcomings.  It  then  considers  the  concept  of  rendezvous  and  shows  how  this  concept 
has  influenced  the  design  of  the  Green  tasking  facilities  It  finally  discusses  the  decisions  involved 
in  the  design  of  the  different  tasking  features. 


11.4.1  Early  Primitives 

The  understanding  of  algorithmic  sequential  processes  is  based  upon  that  of  the  evaluation  of 
arithmetic  and  Boolean  expressions  whose  axioms  have  been  well  understood  for  centuries 
However,  there  is  no  mathematical  tradition  upon  which  we  can  draw  in  order  to  help  us  to 
understand  the  behavior  of  cooperating  sequential  processes  As  a consequence  it  has  been  dif 
ficult  to  decide  whether  a particular  set  of  real-time  primitives  is  good  or  not  Many  sets  can  be 
implemented  in  terms  of  each  other  but  their  relative  primitiveness  is  often  hard  to  perceive 

Broadly  speaking  the  primitives  (or  perhaps  the  applications)  can  be  divided  into  two  categories 
The  first  enables  common  data  or  common  code  to  be  protected  from  multiple  usage  The  second 
enables  one  task  to  send  a message  to  another;  this  includes  the  degenerate  case  of  a signal 
which  can  be  thought  of  as  a message  with  no  contents 

One  of  the  oldest  and  best  known  primitive  sets  is  the  boolean  semaphore  described  by  Dijkstra 
l Di  S8|.  This  consists  of  the  two  operators  P and  V acting  on  a semaphore  S which  takes  two 
values  busy  and  free  (or  equivalently  true  and  false)  The  behavior  of  the  operations  is: 

P(S)  If  S is  busy  the  task  is  suspended  until  S becomes  free.  If  S is  free  then  it  is  set  busy  and 
the  task  proceeds. 

V(S)  S is  set  free.  If  there  are  tasks  held  up  on  a PIS)  operation  then  one  of  them  is  allowed  to 
proceed. 
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Semaphores  can  be  used  to  protect  data  by  surrounding  code  which  accesses  the  data  by  matched 
calls  thus: 

PIS)  PIS) 

— access  data  — access  data 

VIS)  VIS) 

task  A task  B 

Semaphores  can  also  be  used  to  signal  happenings.  One  task  waits  by  calling  P,  the  other  signals 
by  calling  V. 

PIS)  wait  for  B VIS)  signal  to  A 

task  A task  B 

Semaphores  can  therefore  be  used  both  for  protection  and  signalling.  They  also  have  the  merit  of 
being  primitives  that  are  both  simple  to  describe  and  easy  to  understand.  What  then  are  their  dis- 
advantages? Briefly  the  problem  is  that  for  all  but  the  simplest  applications,  the  programming  of 
semaphores  is  difficult.  Programs  using  semaphores  exhibit  similar  symptoms  to  unstructured 
programs  using  gotos  They  are  hard  to  write,  understand,  prove  and  maintain. 

More  specifically,  typical  problems  are: 

• One  can  jump  around  a call  of  P and  therefore  accidentally  access  unprotected  data. 

• One  can  jump  around  a call  of  V and  accidentally  leave  the  semaphore  busy  so  that  the 
system  deadlocks. 

• One  can  forget  to  use  them. 

• It  is  not  possible  to  program  an  alternative  action  if  a semaphore  is  found  to  be  busy  when 
attempting  P. 

• It  is  not  possible  to  wait  for  one  of  several  semaphores  to  be  free. 

• Semaphores  are  often  visible  to  tasks  which  need  not  access  them. 

An  extended  form  of  semaphore  is  the  integer  semaphore.  In  this  case  the  value  is  an  integer 
rather  than  a boolean.  It  is  particularly  useful  for  allowing  a limited  number  of  tasks  to  have  access 
to  a resource.  Nevertheless  it  has  been  shown  that  the  integer  semaphore  can  be  programmed  in 
terms  of  boolean  semaphores  and  so  in  practice  it  is  only  marginally  more  useful. 

Closely  related  to  the  semaphore  is  the  signal  or  event.  There  are  variations  but  a typical  definition 
would  be  that  an  event  E has  two  states,  set  and  unset,  and  the  following  operations  upon  it: 

WAIT(E)  If  E has  not  been  set  then  the  task  is  suspended  until  the  event  is  set.  If  E has  been 

set  then  it  is  unset  and  the  task  is  allowed  to  proceed. 

SEND(E)  E is  set.  If  there  are  tasks  waiting  for  E then  one  of  them  is  allowed  to  proceed 
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Clearly  such  an  event  is  Isomorphic  to  the  Boolean  semaphore.  The  difference  lies  perhaps  in  the 
intended  use.  Semaphores  are  associated  with  data  protection  and  events  with  indicating  that 
something  has  happened.  There  are  variations  in  which  several  events  are  remembered.  But  in  all 
forms,  events  suffer  from  the  same  structuring  problems  as  semaphores. 


Various  other  primitives  have  been  proposed  in  order  to  overcome  the  structuring  difficulties  of 
semaphores  and  events.  Newer  proposals  have  been  put  forth,  but  they  usually  tackle  only  one  of 
the  application  areas  distinguished  above  (data  protection  and  signalling).  In  this  respect  they  are 
somewhat  unbalanced. 

The  critical  section  has  been  proposed  as  a syntactic  form  equivalent  to  a bracketed  pair  of  P and  V 
operations.  This  prevents  goto  statements  from  bypassing  one  of  the  operations  and  hence  over- 
comes some  of  the  difficulties  of  semaphores  A further  form,  the  conditional  critical  section, 
allows  an  alternative  action  to  be  performed  if  the  resource  represented  is  busy. 


Critical  sections  do  not  seem  to  have  been  successful.  They  only  solve  the  exclusion  problem  and 
need  to  be  complemented  with  a signalling  mechanism;  this  does  not  lead  to  the  unification 
sought  by  language  designers. 


Many  forms  of  message  switching  system  have  been  implemented  in  order  to  give  improved  solu- 
tions to  the  signalling  problem  (see  (BH  70,  731).  Typically  they  enable  messages  to  be  sent 
between  tasks  and  allow  the  source  or  destination  of  the  message  to  be  optionally  specified.  They 
therefore  give  added  protection  by  preventing  unauthorized  access  to  messages 


Perhaps  the  biggest  disadvantages  of  message  systems  is  the  need  for  a sizable  message  control- 
ler. Message  systems  also  seem  to  be  of  an  ad-hoc  nature  with  a nonobvious  set  of  parameters. 
Moreover  they  do  not  easily  solve  exclusion  problems  because  of  the  high  overhead  involved 

A significant  step  forward  was  the  monitor  first  described  by  Brinch  Hansen  |BH  73,751  and  by 
Hoare  [Ho  74|.  This  includes  the  facilities  of  the  critical  section  and  when  combined  with  events 
(as  in  Modula).  gives  a reasonable  solution  to  problems  such  as  the  bounded  buffer.  The  monitor 
solves  the  exclusion  problem  but  not  the  message  problem.  Indeed  the  signals  in  Modula  still  suf- 
fer from  all  the  structuring  problems  of  semaphores. 


11.4.2  The  Rendezvous  Concept 


Another  line  of  approach  to  mutual  exclusion  and  synchronization  was  introduced  in  early  com- 
puter science  by  Conway  (Co  631  with  the  notion  of  coroutine,  the  first  definition  of  a high  level 
synchronization  mechanism.  One  of  the  important  concepts  introduced  by  Conway  (and  maybe 
forgotten  later)  is  that  synchronization  and  data  transmission  are  two  inseparable  activities.  Two 
parallel  tasks  need  to  be  synchronized  to  exchange  information,  thereafter  they  resume  their 
respective  activities;  this  synchronization  is  known  as  a rendezvous.  Two  recent  papers  by  Hoare 
IHo  78|  and  Brinch  Hansen  |BH  781  propose  a rethink  of  parallel  processing  in  terms  of  this  con- 
cept of  rendezvous  and  have  strongly  influenced  the  design  of  the  Green  language. 
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The  difficult  problem  that  arises  here  is  one  of  making  tasks  known  to  each  other.  Tasks  have 
names  that  identify  them  unambiguously.  Should  these  names  be  used  by  tasks  to  synchronize 
with  each  other,  or  should  there  exist  a further  entity  that  makes  both  candidates  for  synchroniza- 
tion known  to  each  other  by  reference  to  some  common  channel ? These  two  solutions  are  extreme 
forms  of  symmetric  communication;  either  each  communicating  task  has  full  knowledge  of  its  col- 
league. or  it  has  no  information  at  all.  Both  solutions  appear  in  the  literature:  |Ho  78|  and  IKa  74|. 

We  rejected  the  channel  solution  in  this  design  in  order  to  avoid  an  additional  language  concept 
and  the  dual  connection  mechanism  that  it  requires.  The  solution  adopted  in  Green,  although 
closer  to  the  solution  proposed  by  Hoare  is  asymmetric : one  of  the  two  communicating  tasks 
knows  the  name  of  the  other  one  and  names  it  explicitly;  the  second  task  just  knows  that  it  expects 
some  external  interaction. 

In  order  to  justify  the  asymmetry,  we  first  summarize  the  symmetric  proposal  developed  by  Hoare 
and  embedded  in  a language  which  has  become  known  as  CSP  (Communicating  Sequential 
Processes).  Communication  between  tasks  is  seen  as  synchronized  input-output.  One  task  out- 
puts data  which  the  other  inputs  and  both  tasks  rendezvous  during  the  transfer  - that  is  the  first  to 
arrive  at  its  input  or  ou.put  statement  waits  for  the  other  and  they  both  then  execute  the  I/O  state- 
ments together  (or  apparently  together)  before  proceeding  independently.  Each  task  names  the 
other  in  the  transfer.  The  transfer  can  be  thought  of  as  an  assignment  split  into  two  parts  with  the 
left  side  in  one  task  and  the  right  side  in  the  other.  The  source  and  destination  must  be  compatible 
for  assignment. 

As  an  example  we  will  consider  a task  BUFFERING  to  smooth  variations  in  the  speed  of  output  of 
items  by  a producer  task  and  input  by  a consumer  task  (given  in  section  1 1 .2.5).  The  program  is  as 
follows: 

BUFFERING  :: 

buffer  : (1  ..  10)  item; 

inx,  outx,  count  : integer; 

inx  :=  1;  outx  :=  1;  count  :=  0; 

Icount  < 10;  producer?buffer(inx)  -> 
inx  :=  inx  mod  10  + 1;  count  :=  count  + 1 
1)  count  > 0;  consumer?more()  -> 
consumer  Ibuffer(outx); 

outx  :=  outx  mod  10  + 1;  count  :=  count  - 1 


The  key  language  statements  in  this  example  are: 

X ? Y Input  Y from  task  X 

X I Y Output  Y to  task  X 

On  each  iteration  the  guards  "count  < 10"  and  "count  > 0"  are  evaluated.  If  both  guards  are  true 
then  calls  from  either  the  consumer  or  producer  are  acceptable  and  the  first  such  call  will  be 
waited  for;  if  both  have  already  made  such  a call  and  are  therefore  themselves  waiting  then  a non- 
deterministic  choice  will  be  made;  if  only  one  has  made  a call  then  obviously  that  call  is  taken.  If, 
however,  only  one  guard  is  true  then  only  the  corresponding  call  can  be  accepted  and  the  other 
task  will  wait  until  the  buffer  is  partially  filled  or  emptied  as  the  case  may  be.  In  this  example  both 
guards  cannot  be  false  and  so  the  iterative  process  continues  indefinitely. 


In  the  producer  case  the  statement 
producer  ? butfer(inx) 

moves  the  item  into  the  buffer  directly.  In  the  consumer  case  the  statement 
consumer  ? morel) 

indicates  that  the  consumer  is  ready  and  a subsequent 
consumer  I buffer(out) 

actually  does  the  transfer  The  producer  task  therefore  contains  statements  such  as 

BUFFERING  I X , 

whereas  the  consumer  task  has  pairs  such  as 

BUFFERING  I morel); 

BUFFERING  ? X 

Note  that  morei)  denotes  a structured  value  with  no  components  and  is  used  here  as  a signal. 

As  can  be  seen  the  program  is  readable  although  perhaps  presented  in  a terse  style  by  traditional 
high  level  language  standards.  One  of  the  main  problems  with  CSP  is  that  a (one-to-one)  named 
correspondence  is  required  Because  of  this  symmetry,  it  is  not  possible  to  program  a library 
routine  to  provide  resources  to  arbitrary  users. 

The  preliminary  definition  of  the  Green  language  was  similar  to  CSP  in  its  semantics  except  that 
naming  was  only  one-sided.  Tasks  can  be  characterized  as  services  and  as  users.  A user  certainly 
needs  to  know  the  name  of  the  service  it  is  requesting.  On  the  other  hand  a service  need  not  know 
the  names  of  the  users.  Because  of  this  asymmetry  it  became  possible  to  program  the  library 
routine.  As  a consequence  there  can  be  queues  of  waiting  tasks  associated  with  each  request.  On 
each  successful  rendezvous  just  one  waiting  task  is  served.  In  preliminary  Green  the  transfer  loca- 
tions were  known  as  boxes  and  were  restricted  to  being  simple  names.  Boxes  had  a direction 
associated  with  them  by  analogy  with  procedure  parameters.  The  notion  of  box,  as  a typed  input  or 
output  register  was  also  similar  to  the  notion  of  port  introduced  in  |Ba  701  and  |Wa  72 1. 

The  buffering  example  in  preliminary  Green  was  as  follows: 

path  BUFFERING  (MORE  : in  box;  INJTEM  : in  box  ITEM;  OUTJTEM  : out  box  ITEM) 
BUFFER  : array  (1  ..  10)  of  ITEM: 

INX,  OUTX,  COUNT  : INTEGER; 

Digin 

INX  :=  1;  OUTX  :=  1;  COUNT  :=  0; 

loop 

•elect  MORE  I INJTEM  of 

when  COUNT  < 10  receive  INJTEM  => 

BUFFER(INX)  :=  INJTEM: 

INX  :=  INX  mod  10+1;  COUNT  ;=  COUNT*  1; 
when  COUNT  > 0 receive  MORE  => 

OUTJTEM  :=  BUFFER(OUTX) 

OUTX  :=  OUTX  mod  10  * 1:  COUNT  COUNT  1 
■end  OUTJTEM; 


The  call  in  the  producer  task  was 


connect  8UFFERINGIINJTEM  :=  XI; 

and  in  the  consumer  we  had 

connoct  BUFFERING  (MORE), 
connect  BUFFERING(OUT_ITEM  =:  XI; 

The  interpretation  was  similar  to  CSP  but  the  syntax  was  more  traditional.  The  select  statement 
indicated  the  multiple  choice  and  is  embedded  in  a loop  statement.  The  guards  are  Boolean 
expressions  following  the  reserved  word  when.  An  absent  guard  was  taken  to  be  true  The  guards 
were  followed  by  a synchronization  statement,  receive  or  send  referring  to  a box  of  type  in  or  out 
respectively,  the  text  following  =>  was  obeyed  after  the  corresponding  rendezvous  was  . ni- 
pt e ted. 

The  main  trouble  with  the  facilities  in  both  CSP  and  preliminary  Green  is  that  a double  interaction 
is  required  for  the  consumer.  This  means  that  the  two  calls  really  need  to  be  wrapped  up  into  a 
single  procedure  in  order  to  give  a clean  interface.  It  is  worth  comparing  the  above  with  the  same 
example  written  in  Modula  using  monitors  as  follows. 


interface  module  buffering; 
define  put.  get: 

var  buffer  : array  1 ..  10  of  item; 
inx,  outx,  count  : integer: 
nonfull,  nonempty  : signal: 

procedure  put  (x  : item); 

begin 

if  count  = 10  then  wait(nonfull)  end; 
buffer  (inx)  :=  x; 

inx  :=  inx  mod  10  + 1;  count  :=  count  + 1; 
send(nonempty) 
end  put; 

procedure  get  (var  x : item); 

begin 

if  count  = 0 then  wait(nonempty)  end; 
x :=  buffer  |outx|; 

outx  :=  outx  mod  10+  1 ; count  :=  count  - 1 ; 
send(nonfull) 
end  get; 
begin 

inx  :=  1 ; outx  :=  1 ; count  :=  0 
end  buffering; 

The  producer  and  consumer  process  move  the  items  by  calls  such  as 
put(x)  and  get(x) 
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Perhaps  the  most  important  point  about  CSP  and  Green  is  that  they  offer  mechanisms  which  are 
applicable  to  both  data  protection  and  signalling.  Earlier  attempts  to  develop  features  at  a higher 
level  thar.  semaphores  or  events  (such  as  message  systems  and  monitors)  seemed  to  solve  only 
one  problem  and  by  offering  an  unbalanced  solution  were  not  clearly  better  than  the  original  sim- 
ple primitives. 

An  important  concept  introduced  In  this  final  form  of  the  Green  language  is  the  notion  of  the 
extended  rendezvous.  This  notion  is  a major  jump  to  a higher  level  of  abstraction.  In  the  case  of 
the  task  BUFFERING  this  overcomes  the  need  for  the  double  rendezvous  with  th'  consumer.  This 
is  seen  by  compering  the  example  in  section  11.2.5  with  that  in  11.4.2.  Thus  we  now  have 

BUFFERING. READ(X) 

rather  than 

connect  BUFFERING! MORE); 
connect  BUFFER ING(OUT_!TEM  ; X); 

This  also  illustrates  the  procedural  form  of  entry  call  as  opposed  to  the  specialized  connect  state 
ment.  As  we  have  seen  this  enables  a constant  external  Interface  to  bo  presented  even  if  a change 
of  solution  demands  that  a procedure  be  replaced  by  an  entry  or  vice  versa. 

Thi  extended  rendezvous  is  more  disciplined  since  it  ensures  that  the  same  task  performs  the 
interaction  throughout.  It  should  also  be  observed  that  the  rendezvous  mechanism  is  more  dis- 
ciplined than  a monitor  since  the  accept  statements  appear  inside  a context  (e.g.  following  a 
guard)  from  which  information  can  be  deduced,  thereby  facilitating  both  understanding  and  proof. 

The  introduction  of  entries  rather  than  boxes  leads  naturally  to  the  unification  of  tasks  and 
packages  A task  encapsulates  a collection  of  entries  in  the  same  way  as  a package  encapsulates 
dat»,  and  procedures.  Moreover  there  is  a strong  analogy  between  the  specification  part  in  which 
the  entries  are  specified  and  the  body  containing  the  sequence  controlling  the  critical  actions. 

However,  this  unification  has  its  limits  since  it  has  been  necessary  to  disallow  variables  and 
modules  in  the  visible  part.  This  is  both  for  methodological  reasons  (the  variable  would  appear  to 
be  controlled  by  the  task  although  it  would  not)  and  because  of  the  cost  of  preventing  access  to 
variables  of  an  inactive  task  and  of  implementing  access  if  the  system  is  distributed. 

The  general  applicability  of  the  rendezvous  concept  has  been  confirmed  by  its  use  in  other  exam- 
ples. This  concept  is  well  adapted  to  distributed  systems  (communication  is  achieved  by  entry  cal- 
ls, exchanged  data  is  passed  via  parameters).  From  a more  theoretical  viewpoint,  it  is  interesting  to 
note  that  path  expressions  |CH  74|  can  be  shown  to  be  easily  expressible  in  terms  of  rendezvous 
primitives. 


11.4.3  Task  Declarations 

The  declarative  part  of  a task  body  is  elaborated  each  time  the  task  is  initiated.  This  is  necessary  In 
order  to  ensure  that  on  each  initiation  the  internal  starting  conditions  are  identical;  local  variables 
must  he  reinitialized.  Elaboration  on  initiation  is  also  indicated  by  a consideration  of  task  families 
which  are  discussed  below. 

The  declarative  part  of  a task  specification  on  the  other  hand  is  elaborated  only  once  when  the  task 
is  declared.  This  ensures  that  types  exported  from  the  visible  part  preserve  compatibility  from  one 
activation  to  another.  It  also  indicates  that  typos  exported  from  a family  belong  to  the  family  as  a 
whole  The  difference  in  time  of  elaboration  of  specification  and  body  is  a further  argument  for  the 
separation  of  thuir  texts. 
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11.4.4  Initiation  and  Termination 


The  fork  and  join  mechanism  with  automatic  initiation  on  scope  entry  and  suspension  of  the  parent 
until  exit  was  rejected  in  favor  of  a more  explicit  initiation  mechanism  for  various  reasons. 

Explicit  initiation  gives  more  control  in  repairing  a faulty  system.  It  makes  more  visible  any  orderly 
start-up.  It  is  cleaner  for  repetitive  use  and  easier  to  program  a watchdog  (see  12.4.1). 

Multiple  initiation  is  necessary  so  that  two  cooperating  tasks  can  be  started  together  and  can  then 
each  assume  that  the  other  is  active. 

There  is  a rule  that  a task  cannot  exit  a scope  until  all  tasks  declared  in  that  scope  have  terminated. 
This  is  simply  because  of  the  need  to  have  orderly  control  of  storage  allocation  since  a task  could 
otherwise  access  the  data  of  enclosing  units. 

An  explicit  abort  statement  seems  necessary,  perhaps  reluctantly,  in  order  to  control  a wayward 
process.  Raising  a FAILURE  exception  is  not  adequate  if  the  failed  task  has  for  one  reason  or 
another  programmed  its  last  wishes  in  an  uncooperative  manner.  Unconditional  termination  is  the 
only  consistent  semantics  that  can  be  given  to  the  abort  statement,  if  it  is  to  be  useful.  For  obvious 
scoping  reasons  this  implies  aborting  all  descendant  tasks.  If  an  aborted  task  is  engaged  in  a 
rendezvous,  then  this  rendezvous  must  be  abandoned  as  well  and  its  partner  must  be  informed  (via 
an  exception)  so  that  it  may  know  whether  or  not  the  rendezvous  has  been  completed.  Of  course, 
if  the  partner  is  also  being  aborted  in  the  same  action,  then  no  exception  need  be  raised.  An 
aborted  task  also  has  to  be  removed  from  any  entry  queue  on  which  it  may  have  been  placed  as  a 
result  of  obeying  an  entry  call.  This  does  not  raise  any  exception  but  demands  care  in  the  use  of 
the  COUNT  attribute.  Note  that  the  FAILURE  exception  and  the  abort  statement  can  be  used  in 
conjunction  as  in  the  following  termination  sequence: 

if  T ACTIVE  then 
raise  T.  FAILURE; 
delay  20.0*SECONDS; 

abort  T; 
end  if: 

This  sequence  allows  the  task  T a period  of  20  seconds  in  which  to  terminate  itself  gracefully 
before  the  abort  statement  is  applied.  If  T has  already  terminated,  the  abort  statement  will  have  no 

(effect. 

The  abort  statement  is  provided  for  emergency  use  only.  Its  overuse  could  severely  hinder 
program  understanding  and  validation. 


11.4.5  Examples  of  Task  Hierarchy 


It  is  most  important  that  the  reader  should  understand  the  distinction  between  the  parent  of  a task, 
the  initiator  of  a task  and  the  task  embracing  the  declaration  of  a task.  In  most  cases  these  will  be 
the  same  task  but  they  can  be  distinct.  This  section  contains  (perhaps  somewhat  contrived)  exam- 
ples to  illustrate  the  possibiliites.  Consider 
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task  body  Z is 
task  W ia 

and; 

taak  body  W ia 

and  W; 

taak  X ia 
procadura  P; 
and; 

taak  body  X la 
taak  Y ia 

and; 

taak  body  Y ia 


procadura  P ia 
begin 

initiata  Y.  W; 
and: 

and  X; 
bagin 

initiata  X; 

X.P; 
and  Z; 


Task  Z calls  procedure  P in  X which  results  in  the  initiation  of  tasks  Y and  W.  The  parent  of  Y is 
however  X and  not  Z.  The  parent  of  W is  Z.  Note  that  X is  guaranteed  to  be  active  since  otherwise 
P could  not  have  been  called.  The  procedure  P could  equally  have  been  called  by  X. 

Note  that  in  the  above  example,  if  X had  been  a package  and  not  a task,  the  parents  of  both  Y and 
W would  have  been  Z Furthermore  suppose  that  P contains  a local  task  V. 

procadura  P is 
task  V ia 

and  V; 

bagin 

initiata  V; 
and; 


Then  if  procedure  P is  called  from  Z , then  Z is  the  parent  of  V whereas  if  P is  called  from  task  X 
then  X is  the  parent  of  V. 
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11.4.6  Task  Families 


The  task  family  is  a useful  and  necessary  concept  for  several  reasons. 

It  is  a common  requirement  to  have  many  similar  tasks  active  simultaneously.  If  the  number  is  at 
all  large,  then  the  declaration  of  several  different  tasks  (or  even  their  generic  instantiation)  could  be 
tedious.  Moreover  these  mechanisms  are  constrained  to  occur  only  at  scope  entry  (Thoughts  of 
recursive  procedures  containing  generic  instantiations  are  not  fruitful). 

The  task  family  provides  a model  of  several  tasks  and  the  individual  tasks  are  designated  by  the 
members  of  the  family.  The  number  of  possible  active  tasks  in  the  family  is  of  course  determined 
by  the  range  in  the  task  declaration  and  can  be  evaluated  on  scope  entry.  Moreover  the  explicit 
initiate  statement  enables  the  number  of  members  actually  used  to  be  closely  controlled. 

It  is  important  to  notice  that  types,  constants,  and  exceptions  declared  in  the  visible  part  belong  to 
the  family  as  a whole.  This  is  desirable  so  that  an  exported  type  is  equivalent  over  all  members  of 
the  family.  On  the  other  hand,  entries  and  procedures  belong  naturally  enough  to  the  members  of 
the  family  since  they  are  the  means  of  communication  with  the  individual  members.  Observe  that 
this  distinction  does  not  exist  with  generics.  Each  instantiation  gives  rise  to  a new  version  of  any 
visible  type.  Task  families  are  significantly  different  from  generics  in  this  respect. 


11.4.7  Implementation  of  Task  Creation 


The  implementation  of  task  creation  can  be  either  dynamic  or  static.  Dynamic  creation  means  that 
storage  for  a task  is  allocated  when  the  task  is  initiated.  Static  creation  means  that  storage  for  the 
task  is  reserved  when  the  task  declaration  is  elaborated.  This  choice  is  normally  left  to  the 
implementation  since  the  optimal  strategy  is  not  the  same  on  all  machines.  However  it  is  possible 
to  influence  the  choice  of  the  translator  by  the  pragmas 

pragma  CREATION  (STATIC); 
pragma  CREATION  (DYNAMIC); 

These  considerations  apply  to  all  tasks  but  are  particularly  relevant  for  task  families. 

For  a small  family  (one  with  a small  total  storage  requirement)  it  may  be  more  efficient  to  do  a 
static  allocation  in  a manner  analogous  to  a cactus  stack.  This  effect  can  be  achieved  by  the  above 
pragma  used  in  conjunction  with  a length  specification  indicating  the  maximum  space  required  by 
each  task  for  its  data  and  for  the  subprograms  that  it  calls.  This  may  be  especially  useful  for  a fami 
ly  that  remains  permanently  active. 

More  generally,  however,  the  discrete  range  of  a task  family  should  just  be  considered  as  defining 
the  allowable  indices  for  members  of  the  family,  but  it  does  not  mean  that  all  members  have  to  be 
allocated  at  scope  entry.  Consider  the  following  example: 
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type  NAME  is  new  INTEGER  range  1 ..  1000: 

task  PROCESS  (NAMEFIRST  ..  NAME'LAST)  is 
pragma  CREATION  (DYNAMIC); 

— specifications  of  the  entries  of  PROCESS 
and  PROCESS; 

A.  B,  C : NAME; 

TABLE  . array  (1  ..  10)  of  NAME; 

Variables  of  type  NAME  can  be  viewed  as  identifying  individual  tasks  of  the  family  with  names  of 
the  form  PROCESS(A),  PROCESS(B),  and  so  on.  In  addition  values  of  type  NAME  can  be 
remembered  in  arrays  such  as  TABLE,  or  in  record  components.  Task  activations  can  thus  be 
designated  by  the  family  name  (PROCESS)  and  by  a value  of  type  NAME. 

An  activation  of  a task  of  the  PROCESS  family  is  created  by  the  execution  of  an  initiate  statement. 
In  this  example  creation  may  be  dynamic  because  of  the  corresponding  pragma.  In  an  application 
the  role  of  assigning  unique  names  for  tasks  could  be  delegated  to  a procedure  SET_NAME  and 
the  creation  of  the  task  C would  be  achieved  by  the  sequence 

SET -NAME  (Cl; 
initiate  PROCESS  (C); 

Other  languages  such  as  Tartan  |SHW  78)  have  tried  to  achieve  a similar  effect  by  the  introduction 
of  additional  language  constructs.  For  example  Tartan  introduces  a specific  data  type  for 
designating  activations  of  task,  both  in  a named  form  and  in  an  anonymous  manner.  Thus  in  the 
named  form,  the  declaration  of  A,  B,  C would  appear  as 

var  A,  B,  C : activation  of  PROCESS; 

This  named  form  is  safe  but  it  is  clear  that  it  does  not  achieve  more  than  what  the  Green  form  does 
without  introducing  the  additional  concept  of  activation  name.  The  anonymous  form  of  activation 
names  provided  by  Tartan  corresponds  to  what  other  languages  have  called  task  variables.  For 
example  with 

var  ANY-TASK  : actname: 

the  variable  ANY_TASK  would  be  able  to  refer  to  any  possible  task  (for  example  to 
DISK_HEAD_SCHEDULER  or  to  LINE_TO_CHAR).  This  means  that  it  would  be  possible  to  per- 
form entry  calls  such  as 

ANY-TASK.TRANSMIT  (T,  D); 

ANY-TASK. GET-CHAR  (C); 

We  considered  this  possibility  in  this  design  and  rejected  it  as  being  too  low  level  and  incompatible 
with  the  reliability  required  in  embedded  computer  systems.  In  terms  of  complexity  also,  such 
untyped  task  variables  raise  the  same  issues  as  formal  procedures  in  Algol  60  (how  do  we 
establish  that  an  entry  call  is  legal  for  such  untyped  task  variables?).  Finally,  it  would  not  have  been 
consistent  to  introduce  formal  tasks  in  this  manner  in  a language  that  otherwise  does  not  provide 
formal  procedures  and  procedure  variables. 
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Note  that  the  most  important  use  of  anonymous  task  names  can  safely  be  covered  by  existing 
language  concepts  It  corresponds  to  the  case  of  a server  needing  the  ability  to  recognize  its 
customers.  In  such  a case  restricted  private  types  provide  a facility  whereby  a key  may  be  created 
and  handed  to  a task  on  its  first  request.  On  later  requests  the  task  shows  the  key,  thus  enabling 
the  server  to  recognize  the  owner.  The  private  type  mechanism  prevents  forgery  of  the  key.  There 
is  a risk  that  keys  will  get  reused  in  the  future,  since  a normal  mechanism  would  be  to  represent 
each  new  key  as  the  next  integer.  This  risk  is  no  more  than  that  associated  with  remembered  task 
activation  variables  and  indeed  can  be  minimized  to  any  required  degree  by  using  a key  composed 
of  a record  of  several  integers.  Thus  using  just  two  1 6 bit  words  a new  key  can  be  issued  every 
second  for  136  years  without  duplication.  The  TRACK_MANAGER  package  of  section  11.3 
provides  an  example  of  the  use  of  such  keys. 


11.4.8  Procedure  end  Entry  Interfece 


The  possibility  of  having  procedures  as  well  as  entries  in  the  visible  part  of  a task  does  produce 
great  methodological  power.  For  example  we  have  seen  in  the  task  READER_WRITER  in  1 1.2.5 
how  the  procedure  READ  forces  the  entries  START_READ  and  STOP..READ  to  be  called  in  the 
correct  order.  Indeed  without  the  procedure  there  would  be  no  guarantee  that  pairs  of  calls  were 
matched  at  all. 

N 

Variables  have  been  disallowed  from  the  visible  part  of  tasks  for  methodological  reasons  (they 
would  appear  controlled  by  the  task  although  they  are  not)  and  because  of  difficulties  with 
preventing  their  access  when  the  task  is  not  activo.  However  a function  can  be  used  to  read  a 
local  variable  of  a task  in  a controlled  manner. 

It  should  be  realized  that  the  caller  executes  a procedure  himself  whereas  an  accept  statement  is 
executed  by  the  callee  on  the  caller  s behalf. 

A problem  with  allowing  procedures  is  that  it  essentially  gives  the  caller  the  ability  to  probe  around 
in  the  body  of  the  callee.  A major  consequence  is  the  constraint  necessarily  imposed  on  the  posi- 
tion of  the  accept  statement  (accept  statements  cannot  be  executed  by  such  procedures).  Note 
finally  that  on  distributed  systems  (where  tasks  do  not  share  a common  store)  communication  by 
procedure  calls  may  be  disallowed,  all  communication  being  achieved  by  entry  calls.  For  such  entry 
calls,  parameter  passing  would  be  implemented  by  copying. 


11.4.9  Accept  Statement 


The  rationale  behind  the  accept  statement  and  entry  call  is  simply  to  provide  a rendezvous.  In 
some  applications  it  is  necessary  that  a rendezvous  be  achieved  whereas  in  others  it  is  important 
for  the  caller  not  to  be  held  up.  It  is  much  more  difficult  to  program  a rendezvous  in  terms  of  non- 
rpndezvous  primitives  than  vice  versa.  Hence  the  rendezvous  h..s  been  chosen  as  the  natural 
primitive. 

It  is  noted  that  calls  are  accepted  in  simple  order  of  arrival.  The  alternative  of  making  the  order 
depend  on  some  parameter  of  the  call  was  considered  and  rejected  because  of  the  difficulty  with 
implementation  which  could  severely  penalize  the  simple  user.  As  has  been  demonstrated  In  the 
examples,  it  is  possible  to  program  different  strategies  when  necessary. 
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11.4.10  Select  Statement 


It  may  be  felt  surprising  that  the  alternatives  in  a select  need  not  refer  to  different  entries.  One 
motivation  here  is  the  fact  that  if  several  alternatives  are  open,  one  of  them  is  chosen  at  random 
and  there  is  hence  no  reason  to  disallow  the  same  entry  in  two  alternatives.  Another  motivation  is 
the  existence  of  families  of  entries.  If  E(l)  and  E(J)  were  two  entries  and  they  had  to  be  different, 
then  a tedious  runtime  check  would  be  necessary.  The  rule  thus  allows  different  actions  to  be 
programmed  in  a simple  way  on  the  same  entry  but  according  to  different  guards. 

Note  that  the  guards  are  all  evaluated  at  the  start  of  the  select  statement  only.  The  alternative 
semantics  of  evaluating  a guard  only  when  an  entry  is  called  was  considered  and  rejected.  The 
problem  concerns  the  indivisibility  of  evaluating  the  guard  and  accepting  the  call  together.  One 
could  not  afford  to  make  the  guard  evaluation  indivisible  and  so  it  would  be  possible  for  the  calling 
task  to  be  aborted  during  the  guard  evaluation.  This  would  cause  havoc  if  the  guard  proved  to  be 
true. 

Guard  evaluation  at  the  start  of  the  select  statement  could  be  criticized  on  the  grounds  that  the 
value  of  a guard  may  be  changed  by  another  task  before  an  alternative  is  chosen.  This  is  not  a 
good  argument  since  even  if  the  guard  were  evaluated  when  the  corresponding  alternative  is 
chosen,  there  is  no  guarantee  that  it  might  not  be  immediately  changed.  In  either  case  there  is  a 
danger  with  the  use  of  asynchronously  modifiable  guards  (such  as  those  containing  COUNT  and 
CLOCK,  etc).  Note  that  in  practice  most  guards  are  local  to  the  task  containing  the  select  state- 
ment. In  addition  they  are  most  often  very  simple.  Consequently  several  optimizations  of  guard 
evaluation  are  possible. 

The  rule  for  choosing  one  of  the  open  alternatives  has  been  stated  to  be  at  random.  This  should  be 
treated  in  a statistical  sense.  It  should  not  be  possible  for  a program  to  detect  the  algorithm  used. 
It  would  certainly  be  unwise  to  assume  for  instance  that  the  alternatives  were  taken  in  some  order. 
If  a uniform  strategy  is  desired,  then  it  must  be  programmed  by  using  appropriate  guarding  condi- 
tions. 

The  need  for  the  else  part  has  been  adequately  demonstrated  by  earlier  examples.  It  should  be 
observed  that  the  select  statement  allows  a server  to  choose  between  different  accept  statements. 
There  is  no  corresponding  mechanism  for  a caller  to  choose  between  the  first  of  several  calls.  This 
is  because  of  a fundamental  design  decision:  a task  can  only  be  on  at  most  one  queue  at  a time. 
The  main  motivation  for  this  decision  is  simplicity  and  efficiency  of  the  implementation. 


11.5  Implementation  Considerations 


A possible  implementation  of  the  Green  tasking  facilities  is  outlined  in  this  section.  This  descrip- 
tion should  certainly  not  be  considered  as  the  only  possible  implementation,  inasmuch  as  it  often 
sacrifices  efficiency  for  the  sake  of  a simpler  presentation. 
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1 1 .5. 1  General  Description 


The  proposed  implementation  is  oriented  towards  machine  configurations  consisting  of  one  or 
more  processors  accessing  a common  memory.  It  is  also  assumed  that  processors  can  be  inter- 
rupted. in  particular  by  a clock. 

An  implementation  of  the  tasking  facilities  must  consider  the  four  following  points:  storage  alloca- 
tion organization  of  queues,  implementation  of  scheduling,  and  implementation  of  the  select 
statement  The  choices  made  in  this  implementation  are  presented  below. 


11.5.1.1  Storage  Allocation 

The  storage  necessary  for  a task  includes  that  needed  for  control  information,  for  local  objects,  and 
for  activation  ot  subprograms  called  by  the  task.  All  this  information  is  found  in  what  is  called  a 
task  activation  record.  These  task  activation  records  are  allocated  in  the  space  of  the  enclosing 
task,  when  the  declaration  of  the  local  task  is  elaborated.  This  strategy  corresponds  to  a static 
allocation,  as  the  storage  is  allocated  as  long  as  the  task  can  be  named,  independently  of  its  initia- 
tions. The  alternative  approach  is  to  allocate  storage  only  at  task  initiation. 


11.5.1.2  Organization  of  Queues 


The  runtime  system  must  maintain  certain  queues  of  tasks.  The  only  queues  actually  needed  are 
the  ready  queue  (containing  the  tasks  that  can  be  run  if  a processor  is  available),  the  entry  queues 
(containing  all  the  tasks  that  have  performed  a call  to  the  entry  considered)  and  the  delay  queue 
(containing  all  the  tasks  that  have  executed  a delay  statement  which  has  not  yet  expired). 

The  entry  queues  and  the  delay  queue  are  simple  linked  lists,  whereas  the  ready  queue  has  a more 
elaborate  structure:  a small  number  of  priorities  is  assumed  (for  example  5).  and  the  ready  queue 
consists  of  separate  linked  lists,  one  per  priority. 

I 

Except  for  the  delay  queue,  a task  is  entered  at  the  tail  of  a queue,  and  is  generally  removed  from 
the  head  This  policy  reflects  the  first  in,  first  out  scheduling  imposed  by  the  language.  The  delay 
queue  is  always  sorted  by  completion  date,  that  is,  the  task  with  the  earliest  completion  time  is 
first  in  the  queue 
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1 1 .5. 1 .3  Implementation  of  Scheduling 


when  a process  must  be  scheduled,  the  ready  queues  are  examined  in  decreasing  order  of  priority. 
The  first  process  on  the  first  nonempty  queue  is  selected  and  removed  from  its  queue.  Deciding 
when  the  scheduler  should  be  invoked  is  a choice  left  to  the  implementor.  For  instance  a scheduler 
may  guarantee  a certain  percentage  of  process  time  to  each  priority  level,  use  time  slicing,  etc. 
These  strategies  do  not  affect  the  language  concepts.  They  could  vary  from  one  implementation  to 
another.  Alternative  scheduling  strategies  may  also  be  provided  for  the  same  implementation. 

In  the  implementation  outlined  here,  a simple  policy  is  used:  the  scheduler  is  invoked  either  when 
a processor  becomes  available,  or  when  a new  task  is  entered  in  the  ready  queue.  This  corres- 
ponds to  the  following  situations: 

• initiation  of  a task. 

• termination  of  a running  task: 

• entry  call; 

• reaching  an  accept  statement  for  which  no  call  has  been  issued,  or  a select  statement  for 
which  there  is  no  possible  alternative  for  immediate  execution; 

• termination  of  a rendezvous; 

• execution  of  a delay  statement; 

• expiration  of  a delay; 

• reception  of  an  interrupt  awaited  by  a task. 

An  additional  scheduling  decision  must  be  made  when  a task  alters  its  priority. 


11.5.1.4  Implementation  of  the  Select  Statement 


Various  schemes  can  be  devised  to  choose  an  alternative  in  a select  statement.  In  order  to  simplify 
the  presentation,  we  assume  that  a random  number  generator  is  used  to  select  an  alternative 
when  several  alternatives  are  open. 

We  shall  now  proceed  with  the  detailed  description  of  the  information  needed  at  runtime,  and  of 
the  various  operations  associated  with  the  tasking  facilities. 
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1 1 .5.2  Information  Needed  at  Runtime 


Four  categories  of  runtime  information  are  considered: 

• information  associated  with  a particular  task 
e information  associated  with  a unit  that  contains  a task  declaration 
e information  associated  with  an  entry 

• global  information  about  the  whole  system. 

11.5.2.1  Information  Associated  with  a Task 

This  information  can  be  stored  in  the  task  activation  record.  It  includes: 

(a)  The  Context  of  the  Task: 

This  is  the  information  required  to  reactivate  a suspended  task.  It  includes  the  value  of  the 
program  counter,  a pointer  to  the  current  subprogram  activation  when  the  task  was 
suspended,  and  depending  on  the  machine,  the  value  of  other  registers. 

(b)  The  Dynamic  Link 

This  is  a pointer  to  the  activation  record  of  the  unit  that  contained  the  task  declaration. 

(c)  The  State  of  the  Task 

This  is  a boolean  flag  indicting  if  the  task  is  active,  that  is,  if  it  has  been  initiated,  and  has  not 
terminated. 

(d)  The  Task  Priority 
(el  The  Next  Task  Pointer. 

This  is  used  to  chain  together  the  tasks  that  are  on  the  same  queue.  Since  a given  task  can  - 

only  be  in  at  most  one  queue  at  a given  time,  only  one  such  field  is  actually  needed 

|| 

(f)  The  Entrv  Descriptors  (see  section  11.5.2.3) 

A pointer  [first  entry)  is  found  at  a fixed  offset  in  the  task  activation  record,  containing  a 
reference  to  the  first  entry  descriptor.  The  number  of  entries  is  also  stored. 

(g)  The  Pending  Exception  Field 

This  identifies  an  exception  that  may  have  been  received  by  a suspended  task.  The  rules  of  the 
language  guarantee  that  only  one  such  field  is  needed. 

I,  1 
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Additional  storage  may  be  needed  for  recording  the  task  s cumulative  processing  time  and  for 
delay  information,  if  the  task  body  contains  a reference  to  the  CLOCK  attribute  or  a delay  state- 
ment. The  delay  information  merely  consists  of  the  time  at  which  the  task  is  to  be  reactivated 
Since  m the  case  of  multiple  delays  in  a select  statement,  only  one  delay  is  actually  executed  the 
value  of  the  program  counter  is  sufficient  to  indicate  where  processing  should  resume 


11.5.2.2  Units  Containing  Task  Daclarations 


A unit  in  which  tasks  are  declared  must  contain  an  Inner  Task  Counter,  which  gives  the  number  of 
tasks  declared  in  the  unit  that  are  active.  When  a local  task  is  initiated,  this  counter  is 
incremented,  it  is  decremented  upon  termination  of  such  a task.  This  counter  is  needed  for  an 
efficient  implementation  of  the  rule  that  a scope  cannot  be  left  before  all  local  tasks  have  ter- 
minated. 


A boolean  variable  is  needed  to  indicate  if  the  execution  of  the  unit  has  reached  its  final  end  but  is 
not  yet  terminated  because  of  the  existence  of  active  local  tasks 

A unit  containing  declarations  of  task  families  whose  bounds  are  not  known  at  compile  time  must 
also  contain  indirect  references  to  the  task  activation  records  of  each  family.  For  all  other  tasks 
the  location  of  the  task  activation  record  within  the  current  unit  can  be  determined  at  compilation 
or  link  edition  time. 


11.5.2.3  Information  Associated  with  an  Entry 


Each  entry  has  an  entry  descriptor,  at  a fixed  offset  in  the  task  activation  record.  This  descriptor 
consists  of  ' 

(a)  The  State  of  the  Entry 

The  state  of  an  entry  is  open  if  the  task  in  which  it  is  declared  is  ready  to  accept  a rendezvous 
for  this  entry,  and  no  call  has  been  issued  It  is  dosed  otherwise. 

(b)  The  Entry  Queue 

All  tasks  that  are  waiting  on  a call  to  the  entry  are  placed  in  this  queue  in  order  of  arrival  The 
entry  descriptor  contains  a pointer  to  the  first  and  last  task  activation  records  on  that  queue 

(c)  The  Transfer  Address 

When  a task  is  suspended  on  an  accept  statement  (waiting  for  the  entry  to  be  called)  the 
value  of  the  program  counter,  saved  in  the  context  of  the  task,  indicates  where  processing 
should  resume  However,  if  the  accept  clause  is  nested  in  a select  statement  the  program 
counter  is  no  longer  sufficient  to  provide  tfiis  information.  When  the  entry  is  opened  the 
address  corresponding  to  a particular  accept  statement  is  saved  in  the  transfer  address  field  of 
the  entry  descriptor. 

It  is  assumed  that  all  entry  descriptors  are  stored  contiguously  in  the  task  activation  record 
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1 1 .5.2.4  Global  Information 


As  described  earlier,  the  runtime  maintains  a ready  queue  and  a delay  queue  for  tasks  that  are 
awaiting  a processor,  or  the  expiration  of  a particular  delay.  Queue  pointers  similar  to  those  used 
for  entries  (head  and  tail  pointers)  are  found  at  a fixed  address  in  the  system.  Additional  informa- 
tion is  gathered  in: 

(a)  The  Processor  Table 

This  table  indicates,  for  each  processor,  the  location  of  the  task  activation  record  of  the  task 
currently  being  executed  on  the  processor  and  the  value  of  the  real-time  clock  when  the 
processor  started  running  this  task. 

(b)  The  Interrupt  Tables 

For  each  interrupt,  the  table  indicates  the  entry  linked  to  the  interrupt.  If  the  entry  has  no 
parameter,  then  the  entry  queue  is  actually  used  as  a counter  which  records  the  number  of 
times  the  corresponding  interrupt  has  been  received  and  not  accepted  by  the  task.  If  the  entry 
has  parameters,  their  value  is  saved  in  a special  storage  area,  and  linked  together  in  a queue. 


11.5.3  Runtime  Routines 


The  outines  described  here  are  invoked  in  different  circumstances.  Some  of  them  should  be 
uninterruptible,  as  they  alter  the  global  information  of  the  system. 


11.5.3.1  Task  Declaration 


For  the  simple  implementation  outlined  here  a static  allocation  scheme  is  used  (as  for  the  pragma 
CREATION(STATIC)).  A task  activation  record  is  allocates  when  the  unit  containing  the  task 
declaration  is  entered  v\  hin  the  storage  space  of  the  enclosing  task. 

The  initialization  of  the  dynamic  link  can  be  done  at  this  point,  and  the  task  state  is  set  to  inactive 
(these  operations  need  not  be  performed  in  uninterruptible  mode). 


11.5.3.2  Task  Initiation 


An  initiate  statement  can  be  performed  in  three  stages: 

(a)  Suspend  the  initiating  task  (saving  its  context). 

(b)  For  each  task  to  be  initiated,  set  the  task  priority  to  that  of  the  initiating  task,  initialize  the  task 
context,  close  all  its  entries,  and  chain  the  task  to  either  the  initiating  one  (if  it  is  the  first  in  the 
initiate  statement),  or  to  the  previously  initiated  task 
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(c)  For  each  initiated  task,  increment  the  inner  task  counter  ot  its  declaring  unit  (found  through 
the  dynamic  link),  and  set  the  task  state  to  active.  Finally,  place  the  initiating  task  and  all 
initiated  tasks  in  the  ready  queue  corresponding  to  their  common  priority  and  invoke  the 
scheduler. 

It  should  be  noted  that  on  a single  processor,  it  is  not  necessary  to  invoke  the  scheduler,  as  the 
initiating  task  can  be  immediately  resumed.  However,  in  the  case  of  multiple  processors,  the  new- 
ly initiated  tasks  may  have  a higher  priority  than  some  of  the  tasks  running  on  other  processors, 
thus  justifying  a scheduling  decision 

These  operations  should  be  uninterruptible.  This  is  mandatory  for  steps  (a)  and  (c).  If  step  (b)  is  to 
be  made  interruptible,  then  each  initiated  task  must  be  set  to  a state  (such  as  being  initiated)  dur- 
ing step  (a),  in  order  to  prevent  another  task  from  attempting  another  initiation  in  parallel. 


11.5.3.3  Task  Termination 


Normal  termination  operations  consist  of 

(a)  Setting  the  task  state  to  inactive. 

(b)  Dec  ementing  the  inner  task  counter  of  the  declaring  unit.  If.  as  a result,  the  counter  becomes 
null,  and  the  declaring  unit  has  reached  its  end  (the  end-of-unit  flag  being  true),  then  the  outer 
task  must  be  resumed,  by  entering  it  in  the  appropriate  ready  queue.  The  corresponding  task 
activation  record  can  be  found  by  following  the  dynamic  chain  of  activations  until  a task 
activation  is  encountered. 

(c)  Entering  the  scheduler  to  find  a new  task  to  be  run. 

All  these  operations  must  be  uninterruptible  because  both  the  task  state  and  the  inner  task  counter 

could  be  accessed  by  other  tasks. 


11.5.3.4  Entry  Call 


When  a task  S calls  an  entry  E of  a task  T: 

(a)  The  actual  parameters  are  evaluated;  their  values  are  then  available  in  the  activation  record  of 
S. 

(b)  The  task  S is  suspended  (the  program  counter  and  current  activation  pointer  are  saved)  and 
placed  on  the  entry  queue  of  E. 

(c)  If  E is  open,  then  all  other  entries  of  T are  closed;  the  transfer  address  for  E is  copied  in  the 
program  counter,  and  T is  entered  in  the  appropriate  ready  list.  If  T was  in  the  delay  list  it  is 
removed;  if  T was  the  first  task  in  the  delay  queue,  the  timer  must  be  reset  to  a value  cor 
responding  to  the  delay  time  of  the  next  task  in  the  delay  queue 

(d)  A new  task  is  chosen  by  the  scheduler. 
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Steps  (b)  through  (d)  should  be  uninterruptible  Note  that  in  step  (b).  the  first  entry  field  of  the  task 
is  used  to  find  all  the  entry  descriptors  that  are  stored  contiguously. 


11.5.3.5  Reaching  an  Accept  Statement 


When  reaching  an  accept  statement  for  an  entry  E two  cases  are  possible: 

(1)  If  the  waiting  queue  of  E is  empty,  then: 

(a)  The  state  of  the  entry  is  set  to  open. 

(b)  The  current  value  of  the  program  counter  for  the  task  is  saved  in  the  transfer  address 
of  E. 

(c)  The  task  is  suspended  (not  placed  in  any  queue)  and  e new  task  is  scheduled. 


(2)  If  the  waiting  queue  of  E is  not  empty,  then  a rendezvous  can  be  accepted  immediately:  the 
first  task  in  the  waiting  queue  of  E is  removed  from  that  queue.  A link  to  it  is  saved  on  the 
stack  of  T,  and  the  statements  corresponding  to  the  rendezvous  can  be  executed.  The  same 
sequence  of  actions  should  be  performed  when  the  task  is  reactivated  by  ar  entry  call,  after 
having  been  suspended  in  case  (1). 

Operations  described  in  (1)  are  uninterruptible.  In  (2),  only  the  removal  of  the  caller  from  the 
waiting  queue  is  uninterruptible. 


11.5.3.6  End  of  i Rendezvous 


At  the  end  of  a rendezvous,  the  called  task  must  place  the  calling  task  back  in  the  appropriate 
ready  queue  (this  is.  of  course  uninterruptible).  The  called  task  is  then  suspended,  and  the 
scheduler  is  invoked  (to  deal  with  the  case  of  a caller  having  a higher  priority). 


11.5.3.7  Delay  Statement 


When  a simple  delay  statement  is  executed,  or  inside  a select  statement  if  no  other  alternative  is 
available  for  immediate  execution,  the  wake-up  time  is  computed  by  adding  the  value  of  the  delay 
expression  to  the  value  of  the  real-time  clock.  This  time  is  saved  in  the  delay  descriptor  of  the  task. 
The  task  is  entered  in  the  delay  queue  at  the  place  corresponding  to  the  wake-up  time.  If  it  is 
added  at  the  head  of  the  queue,  then  the  value  of  the  timer  (considered  as  a regisfer  that  is 
decremented  at  each  clock  tick,  and  that  raises  an  interrupt  when  its  value  reaches  0)  must  be 
changed  to  the  new  delav  value.  Adding  the  task  to  the  delay  queue  and  updating  the  timer  must 
be  uninterruptible. 


1 1.5.3. 8 Occurrence  of  i Timer  Interrupt 


When  a timer  Interrupt  la  received,  the  delay  queue  must  be  scanned  All  tasks  having  delay 
values  not  greeter  than  the  current  time  are  removed  horn  the  delay  queue,  and  entered  In  the 
ready  queues  corresponding  to  their  respective  priorities  The  new  value  of  the  timer  Is  determined 
from  tho  smallest  delay  value  of  all  tasks  remaining  on  the  delay  queue.  The  scheduler  must  then 
be  invoked. 

All  those  operations  should  be  uninterruptible. 


1 1 .5.3.8  Select  Statement 


We  describe  hero  a fairly  straightforward  Implementation  of  the  select  statement.  More  efficient  * 
approaches  can  he  devised.  In  tho  absence  of  side  effects  In  guarding  expressions  (the  usual  case). 

All  guards  are  first  evaluated  (In  their  textual  order),  and  their  values  collected  In  a bit  vector.  If  a 
guard  Is  true  and  the  corresponding  alternative  starts  with  a delay,  the  delay  expression  Is 
evalueted  and  compared  with  the  value  stored  In  tho  delay  field  of  tho  task  The  smallest  of  the 
two  values  Is  kept  in  this  field,  and  a reference  to  the  particulai  branch  is  saved  as  tint  task  s 
program  counter  value. 

If  no  guard  Is  true,  and  the  select  statement  doe  not  have  an  else  part,  then  a SELECT  ERROR  Is 
raised  Otherwise,  in  uninterruptible  mode,  the  entnos  corresponding  to  true  guards  are  examined. 

Three  cases  are  possible 

( 1 ) Mora  then  one  such  entry  has  a non-empty  waiting  queue:  a random  numboi  generator  Is  cal 
led  to  choose  one  of  the  possible  alternatives. 

(2)  kxnctly  one  entry  has  a non  empty  waiting  queue:  It  Is  selected  for  immediate  execution 

(3)  All  entry  queues  with  true  guards  aro  empty.  It  an  else  clause  Is  present.  It  Is  executed  If  not. 
the  state  of  all  entries  with  true  guards  Is  sot  to  open,  and  the  address  of  the  code  cor 
responding  to  each  alternative  is  saved  In  the  entry  descriptors  It  the  delay  value  of  the  task  is 
not  null,  the  task  Is  entered  in  the  delay  queue,  ns  described  In  1 1 .5.3  7 and  In  the  other  case 
the  task  Is  merely  suspended. 

Itr  cases  ())  and  (2)  execution  of  tho  task  proceeds  with  the  rendezvous  corresponding  to  the 
selected  alternative  When  tho  task  is  suspended,  the  scheduler  must  he  Invoked 
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1 1.5.3.10  Alternative  Implementations  of  Select  Statements 


Alternative  implementations  of  random  selection  are  possible.  Two  such  methods  are  sketched 
below:  the  select- marker  method  is  particularly  efficient  in  the  presence  of  guarding  conditions 
without  side-effects  (the  most  likely  case),  because  it  avoids  reevaluation  of  some  of  the  guards. 
The  order  of  arrival  method  takes  into  account  the  time  elapsed  since  the  arrival  of  the  tasks  on  the 
various  queues. 

The  select-marker  method 

For  each  select  statement  in  a task,  an  integer  index  is  reserved  in  the  task  activation  record  and 
initialized  to  some  positive  value  in  the  range  1 ..  N,  where  N is  the  number  of  alternatives  in  the 
select  statement. 

When  a select  statement  is  reached,  alternatives  are  considered  in  turn,  starting  with  the  one 
whose  position  corresponds  to  the  index.  The  guard  is  evaluated.  If  it  is  false,  or  if  the  entry  queue 
is  empty,  the  index  is  incremented  by  1 (modulo  N)  and  the  next  alternative  is  considered.  If  the 
guard  is  true  and  the  entry  queue  non-empty,  then  the  alternative  is  immediately  selected  for 
execution  (the  index  is  also  incremented).  At  the  next  execution  of  the  select  statement,  alter- 
natives will  thus  be  considered  starting  with  the  one  immediately  following  the  last  selected  alter- 
native. 

If  all  alternatives  have  been  considered,  and  all  those  with  true  guards  had  empty  queues  at  the 
time  they  were  examined,  then  the  queues  must  be  reexamined  in  an  uninterruptible  mode.  If 
some  of  the  queues  have  become  nonempty,  then  one  of  the  corresponding  alternatives  must  be 
selected  (e.g.  the  one  closest  to  the  index  value),  and  the  index  appropriately  updated. 

The  order  of  arrival  method 

In  this  method,  each  task  containing  entry  declarations  has  a global  entry  call  counter,  to  hold  suf- 
ficiently large  integer  values.  This  counter  is  initialized  to  0.  Each  task  also  contains  a variable  of 
the  same  size  that  holds  the  order  of  arrival. 

Whenever  a task  T issues  a call  to  an  entry  of  a task  U and  the  entry  is  closed,  the  value  of  the 
entry  call  counter  of  U is  incremented  by  1 and  the  new  value  is  copied  as  the  order-of-arrival  of 
task  T. 

When  a select  statement  is  to  be  executed,  the  guards  are  evaluated  and  the  first  task  on  each 
nonempty  entry  queue  is  examined  The  one  with  the  smallest  order-of-arrival  is  selected  for 
execution. 
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1 1 .5.3.1 1 Treatment  of  Interrupts 


When  an  interrupt  is  received,  the  following  interrupt  routine  is  executed: 

The  interrupt  table  indicates  which  entry  is  linked  to  the  interrupt  (it  is  assumed  that  if  an  interrupt 
does  not  correspond  to  any  entry,  it  wilt  be  masked). 

In  the  case  of  a pararneterless  entry,  the  entry  queue  is  replaced  by  a counter  that  is  incremented 
by  1.  If  the  entry  was  open,  all  entries  of  the  task  are  closed  and  the  task  is  placed  in  the  ready 
queue  (after  updating  the  program  counter  with  the  value  stored  in  the  entry  descriptor).  The  inter- 
rupt can  then  be  cleared  and  the  scheduler  entered 


In  the  case  of  an  entry  with  parameters  (In  only),  the  values  are  read  at  specified  addresses.  Space 
is  obtained  from  a special  storage  area  to  copy  these  values,  and  this  space  is  attached  to  the 
queue  of  the  entry. 

The  nature  of  the  interrupts  that  could  be  received  during  execution  of  this  routine  and  what  would 
happen  to  interrupts  that  are  masked  is  machine  and  implementation  dependent  and  thus  not 
described  here. 


11-51 


12.  Excaption  Handling 


12.1  Introduction 


The  ability  to  handle  error  situations  is  essential  for  reliability  of  real  time  systems.  In  many  cases, 
they  must  be  designed  as  systems  which  should  never  halt.  This  definitely  requires  an  ability  to 
handle  situations  which,  although  rare,  are  quite  likely  to  happen  given  enough  time. 

This  subject  of  exception  handling  has  received  considerable  attention  in  recent  years,  and  several 
language  formulations  of  exception  handling  features  have  been  proposed.  For  a presentation  of 
these  facilities  the  reader  is  referred  to  the  extensive  accounts  given  in  |Go  7 5 1 and  (Le  7 7 1 . The 
solutions  proposed  differ  mainly  on  the  level  of  generality  they  give  to  the  concept  of  exception. 

A first  family  of  solutions  tends  to  consider  exception  handling  as  a normal  programming  techni- 
que for  events  that  are  infrequent,  but  not  necessarily  errors.  This  viewpoint  has  been  followed  in 
[LMS  74|,  [Go  75|,  )PW  76),  l Le  77)  and  )GS  77).  It  moans  that  when  an  exception  occurs  it  is 
treated  by  an  exception  handler,  and  then  control  may  return  to  the  point  where  the  exception 
occurred.  It  also  means  that  exception  handling  may  be  used  to  perform  some  repair  actions  and  to 
continue  normal  execution  thereafter. 

A second  family  of  proposals  tends  to  restrict  exceptions  to  events  that  can  be  considered  (in  some 
sense)  as  errors  or,  at  least  as  terminating  conditions.  This  means  that  when  an  exception  occurs  in 
a given  program  unit,  its  execution  will  be  terminated.  Control  will  be  passed  to  an  exception 
handler  but  will  never  return  to  the  point  where  the  exception  occurred.  The  handler  may  decide  to 
restart  the  same  sequence  of  actions  under  better  conditions,  but  it  will  do  so  by  a different  invoca- 
tion of  these  actions,  not  a simple  resumption. 

This  second  family  of  so'  tions  includes  recovery  blocks  IHLMR  74,  Ra  75)  and  a recent  proposal 
by  Bron,  Fokkinga  and  De  Hass  |BFH  76).  The  Steelman  requirements  for  exception  handling 
clearly  require  a solution  in  this  second  family,  since  they  specify  that  the  occurrence  of  an  excep- 
tion should  cause  transfer  to  a handler  without  completing  the  elaboration  of  the  declaration  or  the 
execution  of  the  statement  where  the  exception  occurred. 

Naturally,  what  is  considered  as  an  error  is  rather  subjective,  and  the  ability  of  a handler  to  rein- 
voke a subprogram  that  raised  an  exception  will  permit  the  use  of  exception  handling  for  making 
repairs  and  for  the  treatment  of  rare  events.  The  problem  domains  that  can  be  addressed  by  the 
two  families  of  solutions  are  hence  comparable,  but  they  require  different  programming  styles  and 
different  underlying  mechanisms. 

The  exception  handling  facility  provided  in  the  Green  language  belongs  to  this  second  family.  It 
provides  a facility  for  local  termination  upon  detection  of  errors  It  has  been  inspired  by  the  Bron 
proposal  and  has  some  similarities  with  the  Bliss  signal  enable  construct  |DEC  74| 
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II 

Our  goal  in  this  design  has  been  to  define  an  exception  handling  facility  involving  a minimum 
number  of  concepts  and  well  integrated  with  the  facilities  for  parallel  processing.  A major  goal  was 
to  have  a solution  compatible  with  an  axiomatic  definition,  hence  permitting  program  verification 
and  mechanical  program  optimization. 

The  discussion  of  exception  handling  starts  by  an  overall  presentation  followed  by  examples 
illustrating  the  main  classes  of  uses.  The  interactions  betwoen  exceptions  and  parallel  processing 
are  then  presented  and  we  conclude  by  a discussion  of  several  technical  issues. 


12.2  Presentation  of  the  Proposal  for  Exception  Handling 


The  definition  of  an  exception  handling  facility  must  provide  answers  to  the  following  questions: 
e How  are  exceptions  declared? 

• What  are  exception  handlers  and  in  which  part  of  a program  can  they  appear? 

• How  are  exceptions  raised? 

e Which  handler  gets  executed  when  an  exception  is  raised? 

• How  can  an  exception  be  reraised? 

• How  can  exceptions  be  suppressed? 

We  next  examine  these  different  questions  in  the  case  of  sequential  programs.  The  case  of  parallel 
tasks  is  discussed  in  section  12.4. 


12.2.1  Declaration  of  Exceptions 


The  name  associated  with  an  exception  condition  must  be  declared.  The  form  of  an  exception 
declaration  is  shown  by  the  following  example: 

SINGULAR  : exception; 

Conceptually  we  may  view  the  set  of  all  exception  declarations  appea.ing  in  a program  as  forming 
the  equivalent  of  a distributed  declaration  of  the  literals  of  an  enumeration  type,  say  exception 
condition,  whose  values  may  only  be  mentioned  in  exception  handlers  and  in  raise  statements. 
Thus  the  above  declaration  has  the  meaning  that  SINGULAR  is  one  of  the  possible  exception  con- 
ditions. 

Declarations  for  predefined  exceptions  such  as  INDEX_ERROR,  RANGE_ERROR,  TASKING_ER- 
ROR.  OVERFLOW,  etc.  are  provided  in  the  predefined  environment. 
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12.2.2  Excaption  Handlers 


Exception  handlers  are  the  sections  of  the  program  to  which  control  is  passed  when  exceptions 
occur.  Each  exception  handler  has  the  form  of  a sequence  of  statements  prefixed  by  the  reserved 
word  whan  followed  by  the  names  of  the  exceptions  serviced  by  the  handler  considered. 

Exception  handlers  may  only  appear  at  the  end  of  a subprogram  body,  module  oody.  or  block  after 
the  reserved  wora  exception.  As  an  example  the  following  block  contains  a single  handler  that  ser- 
vices the  exception  SINGULAR; 

begin 

— sequence  of  statements 

exception 

when  SINGULAR  = > 

PUTCmatrix  is  singular'); 

end; 

A handler  started  by  when  others  services  all  exceptions  for  which  no  explicit  handler  is  given  in 
the  same  program  unit.  Note  finally,  that  any  sequence  of  statements  with  which  an  exception 
handler  is  needed  can  always  be  made  into  a block. 


12.2.3  The  Reise  Stetement 


There  are  two  possible  reasons  for  an  exception  to  be  raised  in  a given  program  unit.  It  may  either 
be  explicitly  raised  by  a raise  statement  or,  as  we  will  explain  later,  it  may  be  propagated  by  sub- 
programs (including  operators)  and  blocks  executed  by  the  program  unit  considered. 

The  main  form  of  raise  statement  includes  the  reserved  word  raise  and  the  name  of  the  exception 
that  is  raised: 

raise  SINGULAR; 

raise  FILE_HANDLING.END_OF_FILE; 

The  name  of  the  exception  must  of  course  be  visible  at  the  point  of  the  raise  statement.  It  may 
have  the  form  of  a selected  component  as  in  the  above  case  of  the  exception  END_OF_FILE 
declared  in  the  package  FILE_HANDUNG. 


12.2.4  Association  of  Handlers  with  Exceptions 


We  next  examine  the  question  of  finding  which  handler  gets  executed  when  a given  exception  is 
raised.  Note  that  if  a program  unit  contains  a raise  statement  for  a given  exception,  it  does  not 
necessarily  contain  a handler  for  that  exception. 

For  example,  in  the  procedure  P given  below,  both  the  procedures  P and  R provide  a handler  for 
SINGULAR  and  have  no  explicit  raise  statement  for  that  exception.  On  the  contrary,  the  procedure 
Q contains  an  explicit  raise  statement  for  SINGULAR  but  provides  no  handler  for  that  exception. 
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procedure  P it 

SINGULAR  exception 

procedure  Q 
begin 

if  DETERMINANT  = 0 then 
raise  SINGULAR 

end  H 

end  U 

procedure  R is 
begin 

Q 

exception 

when  SINGULAR  => 

— second  handler  for  SINGULAR 

end  R: 

begin  - P 

R Q ... 

exception 

when  SINGULAR  => 

--  first  handler  for  SINGULAR 

end  P; 

When  an  exception  is  raised  within  a program  unit,  we  may  be  in  either  of  the  two  following  situa- 
tions: 

(a)  The  currently  executing  subprogram  or  block  has  no  handler  for  the  exception; 

The  execution  of  the  subprogram  is  terminated  and  the  same  exception  is  implicitly  raised  at 
the  point  of  call  of  the  subprogram.  Similarly  the  execution  of  the  block  is  terminated  ana  the 
same  exception  is  implicitly  raised  after  the  block  in  the  enclosing  program  unit.  In  both  cases 
we  say  that  the  exception  is  propagated. 

(b)  A handler  has  been  provided  for  the  exception: 

The  actions  following  the  point  where  the  exception  is  raised  are  skipped  and  the  execution  of 
the  handler  terminates  the  execution  of  the  current  program  unit. 

In  the  above  example  if  the  exception  SINGULAR  is  raised  during  the  execution  of  Q called  by  R, 
the  execution  of  Q will  be  terminated,  since  no  handler  is  provided  for  SINGULAR  within  Q.  This 
exception  is  then  propagated  to  the  caller:  it  is  raised  within  R at  the  point  of  call  of  Q and  serviced 
by  the  second  handler.  The  execution  of  this  handler  terminates  the  execution  of  R and  the  excep- 
tion is  not  further  propagated.  For  P.  this  call  of  R therefore  appears  as  a normal  call.  Note  that  the 
first  handler  for  SINGULAR,  that  of  P would  be  executed  if  the  exception  were  raised  by  the 
execution  of  Q corresponding  to  its  direct  call  within  P. 

With  this  definition  of  exception  handling,  the  effect  of  a subprogram  is  normally  completed  by  the 
sequence  of  statements  of  its  body:  when  an  exception  occurs,  it  may  be  completed  by  a cor- 
responding handler,  if  present. 
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The  initialization  part  of  a package  body  acts  as  a procedure  implicitly  called  by  the  package  for  its 
initialization.  This  applies  also  for  exceptions.  A handler  in  a package  body  acts  as  a handler  in  a 
procedure.  In  the  absence  of  a handler,  an  exception  is  propagated  to  the  program  unit  containing 
the  package  declaration.  The  case  of  task  bodies  is  discussed  in  Section  12.4. 

Having  explained  the  concept  of  exception  propagation,  it  should  now  be  clear  that  there  is  no 
conceptual  difference  between  the  predefined  exceptions  and  the  exceptions  declared  by  the  user. 
Predefined  exceptions  are  exceptions  that  can  be  propagated  by  the  basic  operations  of  the 
language  such  as  indexing,  accessing  a value  and  the  arithmetic  operations.  As  an  example 
DIVIDE_ERROR  is  an  exception  that  may  be  propagated  by  the  (hardware  supplied)  operation  of 
division. 


12.2.5  Reraising  an  Exception 


Within  a handler,  the  exception  that  caused  transfer  to  the  handler  may  be  reraised  by  a normal 
raise  statement  (mentioning  its  name)  or  by  a raise  statement  of  the  form 


In  either  case,  the  effect  of  reraising  the  same  (or  another)  exception  within  a handler  is  to  tei 
minate  the  current  program  unit  and  to  propagate  the  corresponding  exception  (except  for  tasks  as 
explained  in  section  12.4). 

The  abbreviated  form  for  reraising  an  exception  is  especially  useful  in  the  case  of  a handler  for 
others.  Thus,  such  a handle r can  be  used  to  perform  some  general  clean-up  actions,  such  as  undo 
ing  possible  side-effects,  before  raising  the  same  exception  again.  This  is  made  possible  by  the  fact 
that  the  exception  is  left  anonymous  both  in  the  handler  prefix  and  in  the  reraise  statement 


12.2.6  Suppressing  an  Exception 


It  is  possible  to  indicate  to  the  translator  that  the  detection  of  some  predefined  exceptions  need 
not  be  provided  within  a given  program  unit.  This  is  achieved  by  inserting  a pragma  such  as 

pragma  SUPPRESS(NO_VALUE_ERROR). 

As  a result  the  translator  may  omit  any  extra  code  to  check  that  a variable  has  been  initialized. 
Note  that  this  pragma  is  not  imperative,  and  does  not  mean  that  the  designated  exception  will  not 
be  raised  in  the  program  unit,  as  it  may  be  raised  explicitly,  be  propagated  from  a subprogram 
where  it  has  not  been  suppressed,  or  simply  because  the  translator  did  not  inhibit  the  check.  The 
latter  is  likely  to  be  the  case  if  hardware  detection  of  the  exception  is  available. 

This  facility  is  especially  useful  for  some  predefined  exceptions,  such  as  ASSERT_ERROR  or  N0_- 
VALUE_ERROR,  as  their  detection  may  be  expensive  unless  aided  by  special  hardware. 
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12.2.7  Order  of  Excaptions 


A translator  may  choose  to  evaluate  the  constituent  terms  of  an  expression  in  any  order  that  is 
consistent  with  the  precedence  properties  of  the  operators,  and  with  the  parentheses.  As  a conse- 
quence. the  order  in  which  exceptions  might  occur  in  the  evaluation  of  an  expression  is  not 
guaranteed  by  the  language.  The  formal  semantics  of  the  language  only  defines  the  value  of  an 
expression  whose  evaluation  does  not  raise  any  exception. 


12.3  Examples 


Several  examples  presenting  typical  uses  of  exception  handling  are  discussed  in  this  section. 


12.3.1  Matrix  Inversion 


The  first  example  is  adapted  from  |BFH  76|.  Each  iteration  of  a loop  is  supposed  to  read  a matrix, 
invert  it  and  print  the  result.  If  the  matrix  is  singular  a message  should  be  printed  and  the  program 
should  proceed  with  the  next  matrix. 

procedure  P is 

procedure  TREAT_MATRICES(N  INTEGER)  is 
SINGULAR  : exception; 

procedure  INVERTIM  in  out  MATRIX)  is 
begin 

— compute  determinant  inverse 

- note  : this  may  implicitly  raise  DIVIDE_EKdOR 

— complete  inversion  of  the  matrix. 

exception 

when  DIVIDE_ERROR  raise  SINGULAR 
end  INVERT. 

procedure  TREAT_ONfc  is 
begin 

READIM); 

INVERTIM): 

PRINT(M): 

exception 

when  SINGULAR  -*  PRINTCMatrix  is  singular"); 
end  TREAT_ONE; 

begin  - TREAT_MATRICES 
for  I in  1 ..  N loop 
PRINTCITERATION"). 

PRINTII); 

TREAT_ONE: 
end  loop; 

end  TREATJMATRICES; 

begin  — P 

TREAT_MATRICES(20): 

end: 
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As  this  example  illustrates,  the  occurrence  of  the  predefined  exception  DIVIDE_ERROR  within 
INVERT  is  expected  and  consequently  n appropriate  handler  has  been  provided  On  the  other 
hand,  an  occurrence  of  this  exception  within  READ  or  PRINT  would  cause  termination  of  P,  since 
no  handler  has  been  provided  within  P. 

In  order  to  illustrate  the  dynamic  behavior  of  this  program,  let  us  consider  the  stack  situation  dur 
ing  a call  to  INVERT: 


(1)  P 

TREAT-MATRICES 

TREAT_ONE 

INVERT 


calling  TREAT  MATRICES 
calling  TREAT  ONE 
calling  INVERT 

executing  normal  statements  ot  INVERT 


If  DIVIDE_ERROR  occurs  during  the  inversions,  the  corresponding  handler  will  be  executed. 


TREAT-MATRICES 

TREAT-ONE 

INVERT 


calling  TREAT  MATRICES 
calling  TREAT  ONE 
calling  INVERT 

executing  the  handle i for  DIVIDE  ERROR 


Note  that  during  its  execution,  the  handler  has  access  to  the  local  variables  and  parameters  of 
INVERT.  Here  the  only  effect  of  this  handler  is  to  raise  the  exception  SINGULAR.  As  a conse- 
quence, the  activation  of  INVERT  is  deleted  and  the  exception  SINGULAR  is  propagated  wi'hin 
TREAT-ONE  at  the  point  of  call  of  INVERT  The  handler  of  TREAT-ONE  for  SINGULAR  is  then 
executed. 


(3)  P 

TREAT-MATRICES 

TREAT-ONE 


calling  TREAT  MATRICES 

calling  TREAT  ONE 

executing  the  handler  for  SINGULAR 


In  this  case  the  execution  of  the  handler  terminates  the  execution  of  TREAT-ONE  without 
propagating  an  exception  in  TREAT-MATRICES.  This  leads  to  the  following  stack  configuration 
where  another  iteration  of  the  loop  can  now  be  executed. 


(4)  P 

TREAT-MATRICES 


calling  TREAT  MATRICES 
executing  loop 


The  above  example  is  characteristic  of  a family  of  problems  in  which  a sequence  of  input  objects 
must  be  subjected  to  a given  treatment.  Should  this  treatment  fail  for  one  object  of  the  sequence 
it  would  be  unreasonable  to  abort  the  complete  sequence  Rather,  the  exception  handling  facility 
provides  the  ability  to  do  a partial  termination,  that  of  the  current  object. 


12.3.2  Division 


Consider  the  following  definition  of  the  function  DIVISION: 

function  DIVISiON  (A.  B REAL!  return  REAL  is 
begin 

return  A,'R: 
exception 

when  DIVIDE.  ERROR  s return  REAL  LAST 
end 

Should  DIVIDE^ERROR  occur  during  the  computation  of  A/B,  the  execution  of  the  handler  will 
complete  the  execution  of  the  function  DIVISION  Any  statement  that  is  valid  within  the  sequence 
of  statements  of  DIVISION  is  also  valid  in  the  handler.  Hence  the  handler  may  issue  a return  state- 
ment 

return  REAL  LAST: 
on  behalf  of  the  function. 

This  example  shows  the  nature  of  handlers.  They  must  be  viewed  as  substitutes  ready  to  take 
charge  of  the  operations  in  case  of  error. 


12.3.3  File  Example 


This  example  illustrates  a case  where  exception  handling  is  used  to  treat  an  event  which  is  certain 
to  happen:  reaching  the  end  of  a file.  Naturally  this  example  could  be  formulated  with  an  explicit 
check  for  each  iteration.  Assuming  the  file  to  be  quite  large,  however,  the  body  of  the  procedure 
TRANSFER  may  be  efficiently  represented  as  an  (apparently)  infinite  loop,  and  the  final  actions  of 
the  procedure  performed  by  the  exception  handler  END_OF_FILE. 

procedure  TRANSFER  ia 

use  TEXTJO: 

INF  IN_FILE: 

OUTF  : OUT_FILE: 

C : CHARACTER. 

begin 

OPENONF  'SOURCE-); 

OPENIOUTF.  "DESTINATION-): 

loop 

GET  (INF.  C): 

PUT  (OUTF.  C): 

end  loop 
exception 

when  END_OF_FILE  > 

PUT(OUTF.  EOF): 

CLOSEIINF)- 
CLOSE(OUTF); 

end 
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The  procedure  TRANSFER  trensfers  the  characters  from  the  file  SOURCE  into  the  file  DESTINA- 
TION. At  each  iteration.  GET  is  called  and  eventually  an  END_OF_FILE  exception  will  occur.  As  a 
consequence  the  corresponding  handler  will  be  activated  and  its  execution  will  complete  the 
execution  of  TRANSFER. 

This  example  shows  that  although  many  exceptions  will  correspond  to  error  conditions,  some  of 
them  may  just  be  normal  conditions  for  termination. 


12.3.4  A Package  Example 


The  example  below  reproduces  a skeleton  of  the  TABLE-MANAGER  package  described  in  the 
Reference  Manual  section  7.5. 


package  TABLE-MANAGER  Is 
type  ITEM  is  ... 

procedure  INSERT  (NEW.ITEM 
procedure  RETRIEVE  (FIRST-ITEM 
TABLE-FULL  : exception;  — may 
end; 

package  body  TABLE-MANAGER  is 

procedure  INSERT  (NEWJTEM  : in  ITEM)  is 

H NO_MORE_SPACE  than 
raise  TABLE-FULL; 

I end  M; 

— normal  actions  of  INSERT 

and; 

end  TABLE-MANAGER; 

The  interface  of  the  table  manager  defines  the  operations  INSERT  and  RETRIEVE,  and  the  excep 
tion  TABLE-FULL.  Any  procedure  such  as  Q that  uses  the  package  may  provide  a local  handler  for 
this  ''xception: 

procedure  Q is 

use  TABLE-MANAGER; 

procedure  SAFE_INSERT(ELEMENT  : in  ITEM)  is 
SPARE  ; ITEM; 

b*?NSERT(ELEMENT); 

exception 

when  TABLE-FULL  => 

RETRIEVE(SPARE); 

— perform  normal  treatment  of  spare 
INSERT(ELEMENT); 
end  SAFE-INSERT; 

boQjn 

--  includes  calls  of  SAFE-INSERT  instead  of  INSERT 

end  Q; 


: in  ITEM); 

: out  ITEM); 
be  raised  by  INSERT 
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Within  procedure  Q,  a procedure  SAFE_INSERT  with  a local  handler  tor  TABLE_FULL  is  provided. 
Should  this  exception  be  raised  by  the  body  of  INSERT,  the  local  handler  for  TABLE_FULL  gains 
control  and  is  able  to  perform  a RETRIEVE  before  reissuing  the  same  call  to  INSERT.  Should  an 
exception  occur  again  in  this  second  call,  the  execution  of  SAFEJNSERT  will  be  terminated  and 
the  same  exception  will  be  raised  in  the  calling  environment. 

It  is  worth  mentioning  that  the  body  of  INSERT  is  programmed  in  a robust  manner:  it  keeps  its 
environment  intact  if  it  cannot  accomplish  its  tasks  normally.  It  is  this  property  that  permits 
SAFE_INSERT  to  reissue  a second  call  of  INSERT  when  the  first  call  fails. 


12.3.5  Example  of  Last  Wishes 


The  occurrence  of  an  exception  causes  termination  of  the  procedures  in  the  dynamic  chain  of  calls 
up  to  (and  not  including)  the  first  procedure  handling  the  exception.  Suppose  A handles  a given 
exception,  and 

A calls  B,  B calls  C.  C calls  D 

If  the  exception  occurs  in  D,  the  activations  of  D.  C.  and  B will  be  terminated  in  that  order. 

One  may  want  to  let  these  procedures  express  their  last  wishes  before  disappearing,  for  instance, 
to  perform  some  clean-up  actions  This  can  be  achieved  by  providing  a handler  for  others  in  each 
of  these  procedures.  The  handler  will  then  issue  the  statement 

raise- 

which  reraises  the  same  exception  in  the  calling  environment.  We  are  thus  able  to  achieve  an 
effect  similar  to  that  of  the  UNWIND  clause  of  Mesa  |GMS  77)  without  introducing  a special 
language  construct.  We  illustrate  last  wishes  with  the  example  of  a procedure  performing  opera- 
tions on  a file: 

procedure  OPERATE|F_NAME  . STRING)  is 
F : INOUT_FILE; 

begin 

— initial  actions 
OPENIF,  F_NAME): 

— perform  work  on  the  file 
CLOSE(F): 

--  final  actions 
end: 

Should  an  exception  occur  while  performing  work  on  the  file,  it  would  be  left  in  an  open  state 
when  leaving  the  body  of  OPERATE.  It  is  possible  to  avoid  this  by  expressing  the  corresponding 
corrective  action  in  a handler: 


procedure  SAFE_OPERATEIF_NAME  STRING)  Is 
F : INOUT_FILE: 

btgin 

— initial  actions 
OPENIF.  F_NAME); 

begin 

— perform  work  on  the  file 

exception 

when  others  => 

CLOSEIF), 


end: 

CLOSE(F) 

— final  actions 

end; 

Now,  if  any  exception  occurs,  either  during  the  initial  or  the  final  actions  it  will  be  propagated  to 
the  caller  of  SAFE_OPERATE.  If  however,  the  exception  occurs  within  the  block,  while  performing 
work  on  the  file,  the  inner  handler  will  first  close  the  file  before  propagating  the  exception. 

Similai  techniques  can  be  used  in  parallel  processing  examples  where  a given  task  could  be  left  in 
an  inconsistent  state  waiting  forever  to  receive  the  stop  signal  from  a task  that  died  after  sending  a 
start  signal. 


12.4  Exceptions  and  Parallel  Processing 


The  exception  handling  facility  has  been  presented  so  far  mainly  in  terms  of  sequential  programs. 
As  a consequence  the  concepts  presented  are  valid  within  a task. 

The  ability  for  one  task  to  raise  or  to  propagate  an  exception  in  another  task  must  however  be 
viewed  as  a possibility  with  potentially  extremely  severe  consequences. 

In  no  way  should  such  external  exceptions  be  considered  as  being  normal  terminating  conditions. 
Interfering  asynchronously  with  the  execution  of  a task  may  catch  it  in  a state  where  it  is  not 
prepared  to  respond  to  such  intervention.  There  is  then  always  a risk  of  leaving  the  task  in  a state 
of  confusion  and  also,  of  contaminating  other  tasks  that  were  communicating  with  it. 

The  normal  means  of  communicating  with  a task  is  via  entry  calls.  Hence  most  .situations  in  which 
the  ten  lination  of  a task  must  be  decided  by  another  task  should  be  programmed  by  calling  a 
special  entry,  say  TERMINATE,  of  the  task  to  be  terminated.  The  clear  advantage  of  such  a solution 
is  the  possibility  thus  offered  to  include  accept  statements  for  the  TERMINATE  entry  at  those 
places  where  the  termination  can  be  done  in  an  orderly  fashion. 

For  these  reasons,  the  ability  of  a task  to  raise  or  to  propagate  an  exception  in  another  task  has 
been  substantially  limited. 

A first  limitation  of  the  exception  handling  facility  for  tasks  concerns  exception  propagation 
Contrary  to  what  is  done  foi  subprogram  and  packages,  if  an  exception  is  not  serviced  by  a handler 
within  a task,  the  exception  is  not  further  propagated:  the  task  execution  is  mere.y  terminated 
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Note  that  if  the  exception  were  propagated  to  the  parent  task,  it  would  mean  that  the  child  task 
could  have  an  asynchronous  interference  on  its  parent.  It  would  also  mean  that  the  latter  could  be 
subject  to  simultaneous  such  interferences  from  its  local  tasks. 

The  second  limitation  concerns  the  nature  of  the  exceptions  that  can  be  raised  explicitly  by  one 
task  for  another  task.  This  ability  is  provided  only  for  the  predefined  exception  FAILURE. 

Other  exceptions  may  also  arise  during  task  initiation  and  also  during  communications  between 
tasks.  Unlike  FAILURE,  however,  these  are  synchronous  exceptions  comparable  to  those  that  can 
be  propagated  by  procedure  calls.  The  predefined  exception  TASKING_ERROR  corresponds  to 
several  such  situations. 

We  next  discuss  the  FAILURE  exception  and  the  situations  in  which  a TASKING_ERROR  may 
arise 


12.4.1  Raising  the  FAILURE  Exception  in  Another  Task 

The  only  exception  that  can  be  raised  explicitly  by  one  task  in  another  task  is  the  predefined  excep- 
tion FAILURE.  For  a task  T,  the  exception  FAILURE  is  raised  by  a raise  statement  of  the  form 

raise  T.FAILURE; 

The  effect  of  this  statement  is  as  follows 

(a)  If  the  task  T is  currently  being  executed,  its  execution  is  interrupted. 

(b)  If  the  task  T has  issued  an  entry  call,  two  cases  may  arise: 

• If  the  entry  call  has  not  been  accepted  it  is  cancelled.  The  task  owning  the  called  entry 
is  unaffected. 

• If  an  accept  statement  for  this  entry  is  being  executed,  the  exception  TASKING_ER- 
ROR  is  raised  within  the  unit  containing  this  statement. 

( c)  The  continuation  address  of  the  taVk  is  modified  so  as  to  reflect  occurrence  of  the  exception, 
and  the  task  T is  put  in  the  ready  queue  of  the  scheduler. 

(d)  The  execution  of  the  task  raising  the  exception  may  continue. 

As  for  other  exceptions  a task  may  provide  handlers  for  FAILURE.  The  task  is  thus  given  an  oppor- 
tunity to  perform  some  clean  up  actions  before  terminating.  The  general  schema  of  a task  likely  to 
be  terminated  by  the  FAILURE  exception  is  as  follows: 

task  body  T is 

begin 

— normal  actions  of  the  task 

exception 

when  FAILURE  => 

— perform  clean-up  actions,  for  example: 

— raise  FAILURE  for  local  tasks 

— issue  some  accept  statements 

end: 
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It  should  be  clear  that  raising  FAILURE  for  a task  T cannot  guarantee  the  termination  of  T since  the 
handler  can  contain  arbitrary  statements.  Hence  this  ability  may  be  insufficient  in  situations  where 
time  is  critical,  and  the  abort  statement  appears  as  a necessary  complement  in  such  situations. 
The  sequence: 

raise  T.FAILURE; 

(May  1.5. SECONDS; 

abort  T; 

can  be  used  to  give  T the  opportunity  to  perform  clean-up  operations  and  nevertheless  make  sure 
that  its  execution  does  not  extend  beyond  a certain  delay. 

As  an  example  of  possible  use  of  the  FAILURE  exception,  consider  a situation  in  which  a task 
OPERATOR  must  be  able  to  take  some  default  actions  in  case  it  cannot  obtain  service  from  a 
SERVER  within  a certain  delay  Instead  of  calling  the  entry  REQUEST  directly,  OPERATOR  will  ask 
a local  task  AGENT  to  do  so  and  to  report  completion. 

task  body  OPERATOR  is 
entry  REPORTO  : INFO): 

task  AGENT  is 
entry  ASK; 
end; 


task  body  AGENT  is 
J : INFO; 

begin 

accept  ASK; 

SERVFR.REQUEST(J); 

OPERATOR. REPORT!  J); 

exception 

when  FAILURE  =>  null; 
and; 
begin 

initiate  AGENT; 

AGENT.ASK; 

ultct 

accept  REPORT!!  : INFO)  do 

--  the  answer  was  received  in  time: 

— perform  normal  operations 

end; 

or 

delay  10.0.SECONDS; 

— no  answer  : perform  default  actions 
raise  AGENT.FAILURE; 
and  select; 
end  OPERATOR; 

If  the  server  does  not  answer  the  request  within  the  delay,  the  task  OPERATOR  raises  the  excep- 
tion FAILURE  for  the  local  task  AGENT.  Several  situations  are  then  possible: 

(a)  SERVER  had  not  yet  accepted  the  request  (either  because  of  malfunction  or  because  it  is  still 
busy  processing  requests  from  other  tasks),  the  request  is  just  removed  from  the  queue  of  the 
corresponding  entry  and  SERVER  is  unaffected. 
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(b)  SERVER  is  in  the  middle  of  the  accept  statement  for  the  entry  REQUEST,  an  exception 
TASKING_ERROR  is  raised  within  the  accept  statement. 

(c)  The  request  is  completed  after  the  delay.  Then  if  AGENT  has  already  issued  a call  to  the  entry 
REPORT,  this  call  is  cancelled. 

This  example  illustrates  the  care  that  must  be  taken  when  raising  the  exception  FAILURE.  In 
general,  it  should  be  used  only  in  extreme  situations,  for  example,  to  protect  a task  against  a possi- 
ble malfunction  in  another  task  or  to  terminate  an  erroneous  task. 

Raising  FAILURE  for  another  task  is  a drastic  measure  that  should  only  be  used  when  normal 
means  of  communication  have  failed.  Whenever  termination  can  be  planned,  it  is  preferable  to 
request  it  with  an  entry  call. 

Because  of  its  importance,  th6  FAILURE  exception  prevails  over  any  other  possible  exception. 


12.4.2  Exceptions  Propagated  During  Communications  Between  Tasks 


When  two  tasks  are  attempting  to  communicate  with  each  other,  or  are  engaged  in  a communica- 
tion, an  abnormal  situation  arising  in  one  of  them  may  have  an  effect  on  the  other  one. 

As  a basis  for  discussing  the  various  cases  that  may  arise,  consider  a task  SERVER  providing  a 
procedure  ASK  and  an  entry  UPDATE,  and  a task  CALLER: 

task  SERVER  is 

procedure  ASK  (...); 
entry  UPDATE!...); 
end; 

task  body  SERVER  is 

procedure  ASK  (...)  is 

end  ASK; 
begin 

accept  UPDATE  (...)  do 

--  statements  for  servicing  the  request 
end  UPDATE; 

end  SERVER. 

task  body  CALLER  is 


SERVER.ASK!...); 
SERVER. UPDATE!...); 
end  CALLER; 


The  task  CALLER  is  calling  the  procedure  ASK  and  the  entry  UPDATE.  Abnormal  situations  will 
arise  if  SERVER  is  not  active  at  the  time  of  either  call.  Similarly  an  abnormal  situation  in  SERVER 
may  affect  the  caller. 


12.4.3  Exceptions  Propagated  by  Calls  of  Task  Procedures 


If  an  exception  is  raised  within  the  body  of  the  procedure  ASK,  and  not  serviced  by  a local  handler, 
it  is  propagated  to  the  caller,  as  usual. 

Calling  the  procedure  ASK  is  of  course  only  possible  if  the  task  SERVER  is  active,  otherwise,  the 
exception  TASKING_ERROR  is  propagated  to  the  caller.  In  addition,  there  is  the  possibility  that 
SERVER  may  become  inactive  (either  by  normal  or  by  abnormal  termination)  during  the  execution 
of  ASK.  Again  the  caller  will  receive  the  TASKING_ERROR  exception. 


12.4.4  Inability  to  Achieve  a Rendezvous 


When  CALLER  issues  a call  to  the  entry  UPDATE  of  SERVER,  the  latter  task  may  be  inactive,  in 
which  case  the  rendezvous  cannot  be  achieved.  It  may  also  happen  that  SERVER  is  active  at  the 
time  of  the  entry  call  but  is  not  yet  ready  to  accept  it.  The  calling  task  must  then  be  suspended  until 
SERVER  is  ready.  In  the  meantime,  however,  SERVER  may  become  inactive  (by  normal  or  abnor- 
mal termination)  and  again,  the  rendezvous  cannot  be  achieved. 

In  either  of  these  situations,  the  predefined  exception  TASKING_ERROR  is  raised  at  the  point  of 
the  entry  cal!  in  the  caller. 


12.4.5  Abnormal  Situations  in  an  Accept  Statement 


Once  a rendezvous  is  achieved,  the  accept  statement  is  executed.  During  this  execution  three 
kinds  of  abnormal  situations  may  arise: 

(1)  An  exception  is  raised  within  the  accept  statement. 

(2)  A third  task  disrupts  the  called  task  (i.e.  SERVER),  for  example,  by  an  abort  statement  or  by 
raising  the  FAILURE  exception. 

(3)  A third  task  disrupts  the  calling  task  (i.e.  CALLER),  for  example,  by  an  abort  statement  or  by 
raising  the  FAILURE  exception. 

We  next  analyze  the  consequences  of  each  of  these  three  possible  abnormal  situations  both  with 
respect  to  the  task  issuing  the  entry  call  and  with  respect  to  the  task  containing  the  accept  state- 
ment. 
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An  exception  is  t used  within  an  accept  statement 

ccmiS  8 situation  in  which  a 1 exception,  say  error,  is  raised  within  the  accept  statement  of 


task  body  CALLER  is 


task  body  SERVER  Is 


SERVER  UPDATE!...). 


accept  UPDATE!...)  do 
error 


and  USER: 


and  UPDATE: 
and  SERVER; 


From  the  point  of  v-ew  of  the  caller,  the  accept  statement  is  analogous  to  a procedure  body 
executed  when  the  corresponding  entrv  is  called.  Hence  if  an  exception  is  raised  (and  not  handled 
within  the  accept  statement  itself)  it  should  be  propagated  at  the  point  of  call  of  SERVER. UP- 


However.  from  the  point  of  view  of  the  task  containing  the  accept  statement,  this  statement  is  a 
normal  statement  of  its  body.  Hence  if  an  exception  is  raised  within  SERVER,  it  should  be  handled 
by  a handler  provided  within  that  same  task. 


To  summarize,  an  ordinary  exception  (not  FAILURE)  raised  within  an  accept  statement  and  not 
hand  ed  there  is  propagated  both  in  the  calling  and  in  the  called  tasks.  Both  tasks  may  provide 
handlers  for  the  exception. 


The  called  task  is  disrupted. 

A different  treatment  must  be  employed  if  the  called  task  (i.e.  SERVER)  receives  a FAILURE  excep- 
tion raised  by  a third  task.  The  main  purpose  of  this  exception  is  to  provide  a possibility  of  clean 
termination  for  a task.  Hence  it  would  be  undesirable  to  propagate  this  special  exception  to  a call- 

X.wwSot  ,>sk  wi" nOT  recslve  FAILURE- bu' ,he  |8SS  smere 


Similarly  TASKING_ERROR  is  raised  in  the  caller  if  the 
while  executing  the  accept  statement. 


called  task  is  aborted  by  a third  process 


The  calling  task  is  disrupted. 

In  this  case  there  is  no  point  in  pursuing  the  execution  of  the  accept  statement  since  the  caller  is 
no  longer  waiting  for  its  completion.  Hence,  the  execution  of  the  accept  statement  is  abnormally 
terminated  and  the  exception  TASKING_ERROR  is  raised  in  the  place  of  this  statement.  Note  that 
this  case  may  result  in  disrupting  another  task  as  in  case  2 or  3 above. 

It  is  quite  important  to  realize  that  this  exception  is  not  raised  within  the  accept  statement  itse'f 
but  rather  outside  it,  for  two  reasons. 


First  if  the  exception  were  raised  inside  the  accept  statement,  it  would  be  possible  to  handle  it 
locally  and  thus  to  continue  the  communication  with  a possibly  inactive  task. 


The  second  reason  concerns  the  possibility  of  nesting  accept  statements.  In  such  a case,  should 
the  callers  for  both  the  outer  and  the  inner  accept  statements  be  aborted,  the  called  task  mav 
receive  two  simultaneous  TASKING.ERROR  exceptions.  However,  no  confusion  is  possible  since 
the  termination  of  the  outer  accept  statement  guarantees  that  of  the  inner  accept  statement. 
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1 2.4.6  Example  of  Propagation  of  Normal  Exceptions  for  Tasks 


The  following  program  fragment  shows  a task  USER  which  is  starting  a file  transfer  performed 
asynchronously  by  a task  SPOOLER.  The  procedure  OPEN_IN_OUT  is  used  by  SPOOLER  to  open 
the  two  files.  If  either  of  the  files  is  invalid,  the  corresponding  exception  is  raised  after  possibly 
closing  the  other  file. 

Two  forms  of  input  output  exceptions  may  be  raised  within  the  body  of  the  task  SPOOLER.  The 
exception  END_OF_FILE  is  handled  locally  and  not  propagated.  The  exception  FILE_NAME  ER 
ROR  may  be  raised  within  the  accept  statement  for  the  entry  START_TRANSFER.  The  handler 
provided  within  SPOOLER  simply  prepares  it  for  another  iteration. 

task  SPOOLER  Is 

entry  START_TRANSFER(SOURCE,  DESTINATION  : in  FILE_NAME); 

end: 

task  body  SPOOLER  is 
INF  : IN_FILE; 

OUTF  : OUT.FILE; 

C : CHARACTER 

procedure  OPEN_IN_OUT  (SOURCE.  DESTINATION  : in  FILE.NAME)  is 

begin 

OPENONF,  SOURCE); 

begin 

OPENIOUTF,  DESTINATION); 

exception 

when  FILE_NAME_ERROR  =>  CLOSE(INF);  raise; 


begin 

loop 

begin 

accept  START_TRANSFER(SOURCE,  DESTINATION  ; in  FILE_NAME)  do 
OPENJN_OUT(SOURCE,  DESTINATION); 


loop 

GET  (INF.  C); 

PUT  (OUTF.  C); 

end  loop; 
exception 

when  ENDJ3F_FILE  => 

PUTfOUTF.  EOF); 

CLOSE(INF); 

CLOSE(OUTF); 

when  FILE_NAME_ERROR  =>  null;  — restart  main  loop 

end; 

and  loop; 

end  SPOOLER; 


w 


In  addition  the  occurrence  of  the  exception  FILE_NAME_ERROR  within  the  accept  statement  for 
START_TRANSFER  also  has  an  effect  on  the  calling  task  USER.  The  exception  is  propagated  in 
that  task  where  it  can  be  serviced  by  a local  handler: 

task  body  USER  is 

l_F,  0_F  : FILE  . NAME; 

begin 

begin 

S POOLER. START_TRANSFER(I_F,  0_F); 

exception 

when  FILE_NAME_ERROR  => 

— do  something  on  l_F  and  0_F 

end. 

end: 


12.4.7  Example  of  TASKING  ERROR  in  Nested  Accept  Statements 


Nested  accept  statements  are  illustrated  by  the  example  of  a task  FILTER  buffering  characters 
received  through  the  entry  WRITE  from  slow  producers.  These  characters  can  be  read  in  batches 
by  other  tasks  through  the  entry  READ. 

When  a call  to  READ  occurs,  two  cases  are  possible:  either  FILTER  has  buffered  enough 
characters  to  forward  them  immediately,  or  it  has  not;  in  the  latter  case  the  reader  must  wait  until 
enough  characters  have  been  received.  This  second  possibility  is  handled  by  nesting  an  accept 
statement  for  WRITE  within  the  one  for  READ. 

Abnormal  termination  of  either  a reader  or  writer  should  not  affect  FILTER.  In  particular,  if  a writer 
dies  while  calling  WRITE,  this  should  not  terminate  the  READ  rendezvous.  This  isolation  is 
provided  by  embedding  the  accept  statement  for  WRITE  within  a block  that  provides  a null  handler 
for  TASKING_ERROR. 

Note  also  that  the  incrementation  of  the  indexes  is  done  first  within  temporary  variables.  These  are 
updated  outside  of  the  accept  statements.  Thus  the  values  of  the  indexes  are  maintained  as  correct 
even  in  the  case  of  exceptions. 

task  FILTER  it 

LENGTH  : constant  INTEGER  :=  120; 

entry  READ  (BATCH  : out  STRING!  1 . LENGTH)); 

entry  WRITE  (C  : CHARACTER); 

and: 


body  FILTER  is 


MAX_BUF  : constant  INTEGER  :=  10.LENGTH; 

BUFFER  : array  (1  ..  MAX_BUF)  of  CHARACTER; 

COUNT  : INTEGER  ranga  0 ..  MAX_BUF  :=  0 
INJNDEX.  OUTJNDEX  : INTEGER  ranga  1 ..  MAX-BUF  :=  MAX_BUF- 
TEMRJN  : INTEGER  ran0a  1 ..  MAX_BUF  :=  INJNDEX- 
CHAR  : CHARACTER; 

pracadura  INPUT_CHAR  is 

bsgin 

INJNDEX  :=  (INJNDEX  mod  MAX_BUF)  + 1; 

BUFFER(INJNDEX)  :=  CHAR; 

COUNT  :=  COUNT  + 1; 

snd; 

begin 

loop 

bogin 

sslsct 

whan  COUNT  < MAX_BUF  => 

accspt  WRITE  (C  : CHARACTER)  do 
CHAR  :=  C; 

and; 

INPUT_CHAR; 

or 

accapt  READ  (BATCH  : out  STRING)  1 ..  LENGTH))  do 
wtiila  COUNT  < LENGTH  loop 
bogin 

accspt  WRITE  (C  : CHARACTER)  do 

CHAR  :=  C; 

' 

INPUT_CHAR; 

TEMPJN  :=  INJNDEX; 

axcoption 

whan  TASKING„ERROR  =>  null;  — isolates  from  writer  termination 

and; 

and  loop; 

for  I in  1 ..  LENGTH  loop 

BATCH(I)  :=  BUFFER((OUTJNDEX+l)  mod  MAX_BUF  + 1); 

and  loop; 
and  READ; 

OUTJNDEX  :=  (OUTJNDEX+LENGTH-1 ) mod  MAX_BUF  + 1; 

COUNT  ;=  COUNT  - LENGTH; 

and  solact; 
axcoption 

whan  TASKING.ERROR  => 

INJNDEX  :=  TEMPJN; 
if  INJNDEX  >=  OUTJNDEX  than 
COUNT  :=  INJNDEX  - OUTJNDEX; 

COUNT  :=  INJNDEX  + MAX_BUF  - OUTJNDEX; 

and  if; 

and; 

and  loop; 
snd  FILTER; 
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12.5  Technical  Issues 


The  discussion  of  exception  handling  in  iGo  75)  classifies  exceptions  into  three  categories. 

<a>  Escape  exceptions  which  require  termination  of  the  operation  raising  the  exception. 

(b)  Notify  exceptions,  which  forbid  termination  of  the  operation  raising  the  exception  and  require 
its  resumption  after  completion  of  the  handlers'  actions. 

(c)  Signal  exceptions,  which  leave  the  choice  to  the  handler  between  termination  and  resumD- 

tion.  K 


The  Steelman  requirements  specify  that  the  occurrence  of  an  exception  should  cause  transfer  to  a 
handler  without  completing  the  elaboration  of  the  declaration  or  the  execution  of  the  statement 
where  the  exception  occurred.  Hence  they  rule  out  notify  and  signal  exceptions,  and  quite 
justifiably  so,  since  these  forms  of  exceptions  violate  program  modularity  and  make  optimization 
difficult  if  not  impossible. 


Exceptions  in  the  Green  language  are  thus  of  the  escape  form;  they  serve  only  for  error  situations 
and  as  terminating  conditions,  permitting  a simpler  language  formulation. 


The  technical  problems  concerning  the  interactions  between  exceptions  and  parallelism  have  been 
mentioned  in  the  previous  section.  The  key  idea  was  to  provide  a simple  rule  for  cases  where 
simultaneous  exceptions  occur  in  a given  task.  For  the  TASKING_ERROR  exception,  multiplicity 
can  only  occur  in  case  of  nested  accept  statements,  and  the  outer  exception  prevails  The  excep- 
tion FAILURE  prevails  over  other  exceptions  and  simultaneous  occurrences  of  this  exception  are 
treated  as  a single  occurrence. 


The  remainder  of  this  discussion  will  concentrate  on  the  following  issues: 

• Exceptions  during  the  elaboration  of  declarations 

• Propagation  of  exceptions  beyond  their  scope 

• Suppression  of  exceptions 

• Implementation  of  exception  handling 

• Proving  programs  with  exceptions 
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12.5.1  Exceptions  During  ths  Elaboration  of  Declarations 

The  elaboration  of  declarations  may  involve  the  evaluation  of  some  expressions  and  in  conse- 
quence. exceptions  may  be  raised  during  this  elaboration.  Consider  for  example  the  procedure 

procedure  A(N  : INTEGER)  is 

C : constant  INTEGER  :=  N*N; 

0 : INTEGER  :=  C; 

T : array  (1  ..  C)  of  INTEGER; 

OtflMi 

--  statements  of  A 
exception 

— handlers  of  A 


If  an  exception  occurs  during  the  elaboration  of  the  constant  C.  the  procedure  will  be  in  a state 
where  D is  not  initialized,  and  the  space  for  the  array  T is  not  yet  allocated.  Consequently,  a 
handler  may  not  be  able  to  do  much;  any  reference  to  D or  T will  be  erroneous  and  may  cause  a 
further  exception. 

When  this  risk  is  important,  it  is  always  possible  to  replace  the  expressions  that  may  cause  excep- 
tions by  function  calls  and  to  provide  handlers  within  these  functions.  Another  possibility  is  to 
provide  a special  boolean  flag: 


:=  FALSE; 


procedure  A(N  ; INTEGER)  is 

ELABORATION_DONE  ; BOOLEAN 

begin 

E LABOR ATION_DONE  :=  TRUE; 


exception 

--  handlers  may  test  if  ElABORATION_DONE 


The  design  also  considered  an  alternate  semantics  in  which  the  handlers  are  only  applicable  after 
completion  of  the  elaboration  of  declaration  (hence,  an  exception  arising  during  the  elaboration  of 
the  local  declarations  of  a procedure  would  always  be  propagated).  This  alternate  semantics  was 
rejected  for  implementability  reasons. 


12.5.2  Propagation  of  Exceptions  Beyond  Their  Scope 


Since  exceptions  can  be  propagated  they  can  be  propagated  beyond  their  scope.  It  is  even  possible 
for  an  exception  to  be  propagated  outside  its  scope  and  back  within  its  scope.  Thus,  in  the  follow- 
ing example,  if  B calls  OUTSIDE  and  OUTSIDE  calls  A.  the  exception  ERROR  raised  within  A will 
be  propagated  to  OUTSIDE  and  again  to  B: 


package  D ta 

procedure  A; 
procedure  B. 
and: 

procadura  OUTSIDE  ia 
begin 

DA; 

and 

packaga  body  D ia 
ERROR  : exception 
procadura  A ia 

L. i— 

D#9H1 

...  raiaa  ERROR:  ... 
and. 

procadura  B ia 
begin 

OUTSIDE; 

exception 

whan  ERROR  _=> 

--  ERROR  may  be  propagated  by  OUTSIDE  calling  A 

and: 
and  D: 

In  general  an  exception  propagated  beyond  its  scope  can  only  be  handled  by  a handler  for  others 
It  can  be  further  propagated  or  reraised  by  the  anonymous  form  of  the  raise  statement  (raiaa;). 

This  rule  provides  a simple  and  consistent  interpretation  of  the  above  example  and  it  avoids  the 
complexity  and  runtime  costs  that  would  be  incurred  if  exceptions  propagated  beyond  their  scope 
were  converted  into  a unique  undefined  exception.  This  design  also  considered,  and  rejected,  the 
possibility  of  associating  the  names  of  the  possibly  propagated  exceptions  with  each  procedure 
declaration.  The  main  reason  for  rejecting  this  possibility  is  the  fact  that  this  would  require  extra 
runtime  code  for  filtering  the  propagation  of  exception.  For  example,  if  a procedure  were  declared 
as 

procedure  P(X  : INTEGER)  propagates  A.  B,  C:  - not  legal  in  Green 
its  body  would  have  to  be  compiled  as  the  equivalent  of  the  following  procedure: 
procedure  PIX  : INTEGER)  ia 
begin 
exception 

when  A | 8 | C =>  raiaa: 

when  others  =>  raise  anonymous  exception' 

end  P. 
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We  considered  the  resulting  code  expansion  to  be  too  prohibitive,  especially  in  the  case  of  small 
functions  and  procedures. 

With  the  solution  adopted  in  Green,  the  user  can  always  put  similar  information  in  comment  form. 
The  case  others  covers  all  possible  anonymous  exceptions,  not  just  one. 

The  internal  codes  associated  with  exceptions  must  all  be  distinct  as  are  the  codes  of  the  dif- 
ferent literals  of  an  enumeration  type.  In  general,  this  assignment  of  codes  to  exceptions  must  be 
performed  at  linkage  editing  time. 


12.S.3  Suppression  of  Exceptions 


A given  program  unit,  and  in  particular  a procedure,  may  be  robust,  in  that  it  will  perform  some 
computation,  and  produce  some  result  for  any  value  of  its  input  parameters.  On  the  other  hand,  its 
validity  may  be  guaranteed  for  only  certain  values  of  these  parameters.  The  exception  mechanism 
is  a useful  tool  to  achieve  robustness,  but  this  may  be  gained  at  some  cost  in  efficiency,  since 
detection  of  some  error  situations  may  be  expensive,  unless  aided  by  special  hardware. 

In  some  cases  where  robustness  is  not  an  issue,  or  can  be  attained  by  means  other  than  runtime 
checks,  the  programmer  may  not  wish  to  incur  the  cost  of  checking  foi  possible  exception  situa- 
tions. The  pragma 

pragma  SUPPRESS  |//sr  of  exception  names)'. 

indicates  that  no  check  need  be  performed  for  the  designated  exception  situations.  (Should  such  a 
situation  occur,  behavior  of  the  program  would  be  unpredictable.) 

As  a consequence  the  compiler  may  suppress  checks  for  such  situations,  and  will  do  so  if  it  results 
in  an  optimization.  Note  that  this  pragma  is  an  indication  that  the  user  does  not  care,  as  far  as  the 
validity  of  the  program  is  concerned,  whether  the  checks  are  performed  or  not. 

However,  in  the  case  of  exceptions  whose  detection  is  aided  by  special  hardware,  inhibiting  the 
corresponding  hardware  mechanisms  may  be  costlier  than  actually  performing  the  checks,  hence 
the  pragma  is  not  imperative.  It  does  not  mean  that  the  checks  aie  not  done 

An  alternative  view  of  the  SUPPRESS  pragma  would  be  that  of  a directive  indicating  imperatively 
that  no  check  is  to  be  performed  to  detect  the  exception.  This  approach  would  correspond  to  a 
decision  to  continue  execution  of  a program  in  spite  of  any  erroneous  situation.  It  would  give  an 
appearance  of  robustness  which  might  be  exploited  in  cases  where  the  programmer  knows  that 
the  abnormal  situation  will  have  some  effects  that  can  be  detected  at  a later  time,  but  it  is  in 
opposition  to  the  general  philosophy  of  the  language. 

In  addition,  the  need  to  provide  a semantics  that  reconciles  software  and  hardware  detected 
exceptions  would  have  a negative  effect  on  the  efficiency  of  the  programs.  If  the  pragma  were 
imperative,  then  on  a machine  with  hardware  detected  exceptions,  it  would  be  necessary  to  inhibit 
the  hardware  checks  for  a scope  in  which  the  corresponding  exception  has  been  suppressed. 
Thereafter,  it  would  be  necessary  to  reenable  the  hardware  detection  prior  to  each  call  to  a unit 
outside  that  scope,  and  again  to  inhibit  the  detection  following  a subsequent  return  from  the  call. 
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12.5.4  Implementation  of  Exception  Handling 


One  important  design  consideration  for  the  exception  handling  facility  is  that  exceptions  should 
add  to  execution  time  only  if  they  are  raised. 

Several  techniques  may  be  used  to  reach  that  goal,  and  they  may  differ  from  one  implementation 
to  another  The  essential  idea  is  that  all  processing  costs  should  be  concentrated  on  the  treatment 
of  the  raise  statement.  As  a consequence  processing  of  a raise  statement  may  be  relatively  slow 
In  contrast,  the  elaboration  of  an  exception  declaration  or  that  of  the  body  of  an  exception  handler 
represents  only  translation  time  and  space  costs  They  have  no  influence  on  the  execution  time 

As  a feasibility  proof,  we  outline  a possible  implementation  technique  that  no  runtime  costs  what- 
soever are  incurred  for  exceptions  unless  they  are  raised.  This  technique  has  been  used  for  some 
debugging  systems  and  it  bears  some  resemblance  to  the  technique  used  in  Mesa  IGMS  7 7 1 . The 
basic  principles  are  as  follows: 

(a)  When  an  exception  occurs,  the  specific  runtime  system  that  treats  exceptions  must  be  able  to 
locate  the  addresses  of  the  currently  active  procedure  calls.  This  condition  is  satisi.ed  if.  as  is 
usually  the  case,  return  addresses  are  stored  in  procedure  activations. 

(b)  Knowing  the  address  of  the  code  of  a procedure,  it  must  be  possible  to  locate  the  address  of 
the  code  of  the  first  handler.  Similarly,  given  a handler,  it  must  be  possible  to  find  the  next 
handler.  This  condition  can  be  satisfied  by  chaining  the  handlers  and  by  storing  the  address  of 
the  first  handler  just  before  the  code  of  the  procedure. 

(c)  Each  handler  must  start  with  the  indication  of  the  exception  code  (or  codes)  that  it  services. 
Some  convention  must  be  used  for  the  handler  for  others  which  must  appear  last. 

(d)  When  performing  the  association  of  an  exception  with  a handler,  the  runtime  system  locates 
the  procedure  address  and  from  there  the  chain  of  handlers.  It  may  then  inspect  the  exception 
codes  to  find  the  appropriate  handler,  if  any. 

We  reiterate  that  this  solution  should  only  be  considered  as  an  existence  proof  that  exceptions 
may  be  implemented  at  no  cost  unless  raised.  Other  techniques  may  be  more  suitable  on  alter- 
native machines. 


12.5.5  Proving  Programs  with  Exceptions 


The  problems  of  exception  handling  facilities  such  as  the  PL/I  on  conditions,  which  permit  resump- 
tion after  exception,  are  well  known.  For  instance,  consider  the  consecutive  statements. 

X :=  P + Q; 

Y :=  X - Q: 

assart  (Y  = P); 

Unless  overflow  occurs  in  the  evaluation  of  P + Q,  the  final  assertion  should  be  satisfied.  This 
however  would  not  be  true  if  a handler  for  overflow  were  able  to  provide  a different  value  for  X and 
return  to  the  same  statement  list. 

This  simple  example  shows  the  near  impossibility  of  proving  programs  with  unconstrained  sipral 
and  notify  exceptions.  For  the  same  reasons,  such  programs  are  extremely  difficult  to  optimize. 

12-24 


W 


In  contrast,  for  the  proposal  given  in  the  Green  language,  simple  proof  rules  may  be  given  as  has 
been  shown  by  Bron  (BFH  76J  and  Fokkinga  (Fo  77).  Additional  examples  may  be  found  in  the 
reference  |DH  76).  The  main  idea  is  a consequence  of  the  definition  of  the  role  of  a handler. 

As  mentioned  above,  when  an  exception  occurs  in  a procedure,  the  execution  of  ne  handler 
replaces  the  remainder  of  the  execution  of  the  procedure  considered.  Consequently  the  effect  of  a 
procedure  is  achieved. 

(a)  either  by  its  body  if  no  exception  occurs 

(b)  or  by  the  part  of  its  body  until  the  point  where  the  exception  E occurs  and  then  by  the  handler 
for  E if  E occurs. 

Two  simple  cases  have  been  shown  in  the  programming  examples: 

(1)  In  the  SAFE_INSERT  example  of  section  12.3.4,  we  have  shown  a case  where  these  two 
rules  reduce  to  a simpler  form.  The  effect  of  SAFE_INSERT  is  achieved. 

(a)  either  by  its  body  if  no  exception  occurs 

(b)  or  by  the  handler  TABLE_FULL  if  TABLE_FULL  occurs 


(2)  In  the  file  example  of  section  12.3.3  where  the  exception  END_OF_FILE  is  used  as  a ter- 
minating condition,  the  ef'scts  of  the  procedure  TRANSFER  is  achieved  by  the  succession  of 
the  effects  of 

la)  its  body 

(b)  the  body  of  the  handler  END_OF_FILE 

This  shows  that  with  adequate  programming  conventions,  the  effect  of  a procedure  containing  an 
exception  handler  can  be  characterized  in  a simple  way.  This  simplifies  correctness  proofs.  On  the 
other  hand,  proving  a program  where  exceptions  arise  in  parallel  tasks  remains  a considerably 
more  difficult  problem. 


13.  Qeneric  Program  Unit* 


13.1 


Introduction 


Generic  clauses  provide  a general  facility  for  translation  time  parameterization  of  program  units.  As 
with  other  parameterization  mechanisms,  the  primary  purpose  of  this  generic  facility  is  fnctorlza 
tlon.  so  as  to  bring  about  a reduction  In  the  size  of  the  program  text  while  simultaneously  Improv- 
ing both  readability  and  efficiency. 

Generic  clauses  may  be  viewed  as  a natural  extension  of  subprogram  parameterization  When 
otherwise  Identical  actions  differ  by  the  particular  value  nr  va  liable,  these  actions  may  be  Incor 
porated  In  a subprogram  where  that  value  or  variable  appears  as  a parameter.  Having  thereby  fac 
torhad  the  common  parts,  the  text  becomes  smaller  and  easier  to  read  and  clarical  errors,  involv- 
ing accidental  lack  of  Identity  among  the  several  copies,  are  eliminated.  Moreover,  the  translator 
can  take  advantage  of  this  commonality  to  produce  more  compact  code 

Traditional  parameterization  mechanisms  are  usually  res  ,cted  to  variables  although  the  same 
factorization  arguments  can  apply  when  two  otherwise  identical  program  units  differ  by  soma 
other  property,  such  as  a type. 

A classical  example  is  provided  by  stacks.  In  the  Green  language,  stacks  would  be  typically  for- 
mulated as  a data  type,  encapsulated  with  its  associated  operations  within  a package  Although 
one  may  want  to  have  stacks  of  Integers  and  stacks  of  real  numbers.  It  Is  clear  that  neither  the 
stack  algorithms  (nor  the  proof  of  their  correctness)  depend  upon  the  type  of  the  Items  to  be 
stacked. 

Strong  typing  prevents  the  writing  of  a single  procedure  to  deni  with  ob|ects  which  may  bo  either 
integers,  reals  or  any  subsequently  defined  type.  Hence  another  lenguage  mechanism  is  needed  to 
achieve  this  kind  of  parameterization  by  a type;  this  mechanism  is  the  generic  clause. 

A generic  clause  permits  parameterization  of  the  text  of  a package  or  of  other  program  units. 
Replication  of  text  can  thereby  be  avoided,  yielding  better  readability.  In  addition  the  translator 
may  use  Its  knowledge  of  data  type  representations  to  achieve  certain  optimizations  (e  g.  reusing 
tho  same  code  fpr  stacks  of  integers  and  reals  If  these  types  occupy  the  same  number  of  bits). 
Seen  In  this  light,  such  a generic  facility  provides  a natural  complement  to  strong  typing,  mlnlmlz 
ing  the  unnecessary  duplication  of  both  text  and  code. 

One  of  the  most  common  applications  of  any  generic  facility  is  factoring  out  dependencies  on  par- 
ular  data  types.  Several  existing  languages  have  accordingly  introduced  language  features  to 
-commodate  this  sort  of  parameterization.  By  far  the  most  powerful  Is  that  provided  by  the 
language  EL  1 |We  74|;  this  generality  Is  achieved,  however,  at  the  cost  of  interpreting  types  In  a 
iv  dynamic  fashion,  which  Is  incompatible  with  the  efficiency  and  security  criteria  imposed  in  the 
^•esent  context. 
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Languages  such  as  Simula  [DNM  69 1,  Clu  ILi  74|  and  Mary  (R  74|  offer  a reasonably  elegant 
approach  to  this  problem,  but  all  impose  the  constraint  that  all  objects  are  handled  by  reference. 
This  introduces  additional  overhead  (i.e.,  indirect  access)  even  in  cases  where  such  generality  is 
neither  needed  nor  wanted.  The  language  Euclid  ILHLMP  76J  provides  a facility  which  is  only 
applicable  when  the  alternative  types  are  specified  in  advance  and  can  therefore  appear  as  variants 
of  some  parameterized  type;  the  language  CS  4 l Br  75J  makes  available  a limited  facility  that  may 
only  be  used  in  conjunction  with  predefined  types.  Neither  approach  offers  the  flexibility  that  is 
required  when  the  definition  of  new  data  types  is  viewed  as  the  rule  rather  than  the  exception. 

A review  of  the  shortcomings  of  existing  mechanisms  which  allow  types  to  be  used  as  parameters 
showed  that  it  was  inappropriate  to  introduce  additional  language  features  solely  for  this  purpose, 
principally  because  of  their  relative  complexity.  This  conclusion  is  substantiated  by  noting  that 
essentially  the  same  effect  (and  many  others  as  well)  can  be  achieved  by  far  simpler  means  using 
traditional  macro-expansion  techniques  (although  in  a context  sensitive  manner).  The  problem 
then  reduces  to  integrating  this  well-established  approach  into  the  framework  of  a high  order 
language  at  reasonable  cost. 

In  the  Green  language,  more  sophisticated  sorts  of  parameterization  are  accommodated  by 
generic  program  units,  which  are  a restricted  form  of  context  sensitive  macro  facility.  The  m8in 
objectives  in  providing  this  particular  mechanism  have  been; 

to  allow  an  additional  degree  of  freedom  in  factorization  without  sacrificing  efficiency; 

to  permit  the  translator  to  take  advantage  of  this  factorization  to  minimize  the  size  of  the 
code; 

to  preserve  the  security  that  is  present  for  ordinary,  unparameterized  program  units; 

to  introduce  only  a modest  extension,  with  relatively  small  impact  on  the  rest  of  the  language 
and  its  translator. 


13.2  Informal  Presentation  of  Generic  Facilities 


Any  program  unit  (that  is,  any  subprogram  or  module)  may  be  declared  with  a generic  clause.  This 
clause  defines  translation-time  parameters  which  may  appear  in  the  body  of  the  program  unit. 

A generic  program  unit  is  not  a normal  program  unit.  A generic  subprogram  cannot  be  called;  it  is 
rather  a model  or  template  for  all  program  units  which  can  be  obtained  by  providing  translation- 
time substitutions  for  the  generic  parameters. 

A specific  program  unit  which  corresponds  to  a given  model  is  created  by  a declaration  called  a 
generic  instantiation.  This  has  the  effect  of  creating  a named  instance.  In  the  case  of  a sub- 
program, for  example,  this  named  instance  can  then  be  called  in  the  usual  way.  Thus,  apart  from 
parameterization,  generic  declaration  is  for  program  units  what  a type  declaration  is  for  data 
objects: 
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program  units 
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defining  the  model: 
defining  an  instance: 


data  object 
type  declaration 
object  declaration 


generic  declaration 


generic  instantiation 


13.2.1  Generic  clauses 

A generic  clause  can  be  given  as  a prefix  in  a subprogram  or  module  specification.  It  has  the  form 
generic  l(generic_parameter  );  generic_parameter|)| 

ZZZZt?7Z!Za  n°rmal  Par8meler  deClarati°"'  a specification,  or  a 

I restricted  | type  identifier 

As  an  example,  consider  the  following  generic  procedure: 

generic! type  ELEM) 

procedure  EXCHANGER,  Y : in  out  ELEM)  la 
TEMP  : ELEM: 

begin 

TEMP  :=  Y; 

Y :=  X; 

X :=  TEMP; 
end; 

genenc  subprogram;  here  ,t  ,s  used  in  the  declaration  of  the  variable  TEMP. 


1 3.2.2  Generic  Instantiation 


A generic  initiation  creates  an  actual  instance  of  the  specified  program  unit  by  replacement  of 

procedure  SWAPJNT  la  new  EXCHANGE!  INTEGER)* 
procedure  SWAP_CHAR  ia  new  EXCHANGE(CHARACTER); 
procedure  SWAP_COLOR  ia  new  EXCHANGE(COLOR); 
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The  resultant  program  units  are  ordinary  procedures,  applicable  to  arguments  of  the  corresponding 
type. 


SWAPJNTU.  J): 

SWAP  COLORISHADE  TINT); 

The  fact  that  these  procedures  are  obtained  by  generic  instantiation  does  not  preclude  overloading 
of  the  names  of  operations. 

procedure  SWAP  is  new  EXCHANGE(INTEGER); 
procedure  SWAP  is  new  EXCHANGEICHARACTER); 
procedure  SWAP  is  new  EXCHANGE(COLOR); 

In  general,  a generic  instantiation  has  the  form 

new  name  |(p, eneric_  association  |,  generic. association |)| 

It  can  appear  in  subprogram  declarations  of  the  form 

subprograrn.nature  designator  is  generic  Jnstantiation; 

Note  that  this  form  of  subprogram  declaration  does  not  contain  parameter  declarations  sine  - the 
parameters  of  the  subprogram  thus  declared  are  derived  from  those  of  the  corresponding  generic 
subprogram  Similarly,  a generic  instantiation  can  appear  in  a module  declaration  of  the  form: 

module.nature  identifier  |(discrete_range)|  is  penericjnstantiation; 

The  parameter  associations  given  in  generic  instantiations  have  the  same  form  as  those  given  for 
subprogram  calls,  but  additional  forms  exist  for  generic  parameters  that  are  types  or  subprograms 
since  these  are  not  possible  as  subprogram  parameters.  Thus  the  form 

IformaLparameter  is  I type.mark 

is  used  for  parameters  that  are  types,  and  the  form 

IformaLparameter  isl  |name. (designator 

is  used  for  parameters  that  are  subprograms.  Note  that  both  named  associations  and  positional 
associations  are  possible  as  usual.  Thus  our  previous  example  can  be  equivalently  written  as: 

procedure  SWAP  Is  new  EXCHANGEIELEM  is  INTEGER); 

procedure  SWAP  is  new  EXCHANGEIELEM  is  CHARACTER): 

procedure  SWAP  is  new  EXCHANGEIELEM  is  COLOR); 

The  resultant  program  unit,  obtained  by  generic  instantiation,  can  be  viewed  as  a copy  of  the  cor- 

responding generic  unit  where  each  formal  parameter  has  been  replaced  by  the  corresponding 
actual  parameter.  For  example,  the  declaration  of  SWAPJNT  produces  a procedure  equivalent  to 
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procedure  SWAPJNT(X,  Y : in  out  INTEGER)  le 
TEMP  : INTEGER; 
begin 

TEMP  :=  Y; 

Y :=  X; 

X :=  TEMP; 

•nd; 

A generic  instantiation  need  not  be  performed  in  the  same  declarative  part  as  the  corresponding 
generic  declaration;  it  may  be  performed  at  any  point  where  the  name  of  the  generic  unit  is  visible. 

The  rule  followed  for  the  identification  of  names  within  a generic  unit  in  such  a case  is  similar  to 
that  used  for  subprograms.  All  non-local  identifiers  of  the  body  of  a generic  unit  (other  than  the 
generic  parameters)  are  identified  in  the  context  of  the  generic  declaration.  In  contrast,  the  actual 
parameters  given  in  the  generic  associations  must  be  interpreted  in  the  context  of  the  generic 
instantiation. 

Note  that  this  rule  differs  from  a simple  textual  substitution.  In  the  latter  case  all  identifiers, 
including  non-local  ones,  would  be  inter  -eted  in  the  context  of  the  instantiation.  Hence  it  would 
not  be  possible  in  general  to  obtain  the  effect  of  generic  program  units  by  a simple  (context  free) 
macro  facility. 

To  summarize,  the  generic  parameter  names  are  the  only  unresolved  identifiers  in  the  body  of  a 
generic  program  unit.  For  any  generic  instantiation,  replacements  must  be  provided  for  all  generic 
parameters.  These  replacements  are  to  be  interpreted  in  the  context  of  the  ntiation. 


13.2.3  Types  as  Generic  Parameters 


In  the  simple  SWAP  example  presented  so  far,  very  little  information  about  the  type  given  as  a 
generic  parameter  is  needed.  The  only  operation  assumed  available  for  objects  of  the  type  is 
assignment.  Hence  the  procedure  can  be  applied  to  any  type  for  which  assignment  is  defined:  all 
types  except  restricted  private  types. 

In  general,  when  a type  is  specified  as  a generic  parameter,  it  must  be  considered  as  a private  type, 
with  no  available  operations,  aside  from  assignment  and  the  predefined  comparison  for  equality  or 
inequality.  Even  these  operations  are  denied  if  the  generic  type  is  a restricted  type  specified  as 

restricted  type  T 

Operations  on  objects  of  such  types  (whether  restricted  or  not)  that  are  used  within  the  generic 
body  must  be  given  by  other  generic  parameters.  As  an  example,  consider  the  generic  function 
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generic ( type  ELEM; 

function  ■*"  (U.  V : ELEM)  return  ELEM) 
function  SQUARINGIX  : ELEM)  return  ELEM  is 
begin 

return  X * X; 
end: 

Since  nothing  is  known  a priori  about  the  typo  ELEM  it  would  not  be  possible  to  write  X * X if  the 
specification  of  were  not  provided  explicitly  as  a parameter  of  the  generic  clause.  Instances  of 
SQUARING  can  be  created  by  supplying  the  corresponding  parameters.  For  example,  for 

function  SQUARE  is  now  SQUARING! INTEGER,  '*’); 

the  operation  %"  is  the  operation  defined  as 

function  (U,  V : INTEGER)  return  INTEGER; 

hence,  the  normal  integer  multiplication.  As  a consequence,  the  generic  instantiation  produces  a 
function  body  equivalent  to  the  following: 

function  SQUAREIX  : INTEGER)  return  INTEGER  is 

begin 

return  X * X; 
end: 

Of  course,  other  instantiations  are  possible.  For  example,  we  may  want  to  use  SQUARING  for  vec- 
tors, to  extend  the  component  by  component  multiplication 

function  MULTfX,  Y : VECTOR)  return  VECTOR; 

Thus  with  the  generic  instantiation 

function  SQUARE  is  new  SQUARINGIVECTOR.  MULT); 

we  obtain  a function  returning  the  component  by  component  square  of  a vector. 

Default  values  can  be  defined  for  generic  parameters  that  are  subprograms.  Thus  an  alternate  form 
of  definition  for  SQUARING  is 

generic  ( type  ELEM; 

function  (U.  V ; ELEM)  return  ELEM  Is  ELEM.**”) 
function  SQUARING(X  : ELEM)  return  ELEM  is 
oegm 

return  X • X; 
end; 


The  declaration  of  the  functional  parameter  specifies  that  ELEM."*',  the  operation  "*'  defined  for 
ELEM,  must  be  used  in  the  absence  of  an  explicit  parameter.  Thus,  since  '*'  is  defined  for 
INTEGER,  the  declaration  of  SQUARE  can  be  written  as 


function  SQUARE 


SQUARING(INTEGER): 


Similarly  the  short  form  can  be  used  for  VECTOR  if  a user  defined  '*'  operation  exists  for  vectors 
in  the  scope  of  the  instantiation.  For  other  examples  of  such  default  parameters,  the  reader  can  see 
their  use  for  the  formulation  of  the  standard  input-output  package  in  Chapter  1 4 of  the  Reference 
Manual. 

To  summarize,  any  operation  applicable  to  a type  specified  as  a generic  parameter  must  also  be  an 
explicit  parameter  of  the  generic  clause.  Hence  every  use  of  such  an  operation  in  a generic  unit  can 
be  identified,  and  the  translator  can  check  the  correctness  of  its  text  independently  from  the 
instantiations,  as  for  program  units  that  are  not  generic.  The  information  contained  in  the  generic 
clause  guarantees  that  any  instantiation  that  matches  the  generic  clause  does  produce  a correct 
text. 


13.3  The  Use  of  Generic  Program  Units 


This  section  contains  a number  of  examples  illustrating  the  use  of  generic  program  units. 


13.3.1  Examples  of  Generic  Functions 


The  following  program  fragment  defines  a generic  function  POWER  to  raise  the  value  of  an  object 
of  a type  T to  its  nth  power.  This  exponentiation  is  defined  by  repeated  multiplication  and  the  cor- 
responding multiplication  operation  must  be  supplied  as  an  actual  generic  parameter. 


subtype  NATURAL  is  INTEGER 


INTEGERLAST; 


generic!  typo  T; 

function  OPER(X.  Y : T>  ref 
function  POWER(A  : T;  N : NATUf 
RESULT  : T :=  A; 

begin 

for  I in  2 ..  N loop 

RESULT  :=  OPER(RESULT,  A) 
end  loop; 
return  RESULT; 
end  POWER; 


T)  return  T) 
NATURAL)  return  T Is 
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This  generic  function  can  be  used  to  define  exponentiation  for  types  for  which  a multiplication 
operation  is  known.  For  example: 


function  "**”  is  new  POWERIRATIONAL.  "*•); 
function  •*."  is  new  POWERIVECTOR.  MULT); 

Each  of  these  declarations  defines  an  overloading  of  the  operator  **,  obtained  by  generic  instan- 
tiation. For  example,  the  first  declaration  defines  a function  whose  specification  is  equivalent  to 

function  (A  RATIONAL;  N NATURAL)  return  RATIONAL; 

It  can  be  used  to  exponentiate  rational  numbers  by  repeated  application  of  the  multiplication 
operation  defined  for  this  type.  Note  also  that  the  generic  function  can  be  used  to  apply  any 
meaningful  operation  repeatedly,  for  example  multiplication  of  a rational  by  an  integer  performed 
by  repeated  additions. 

function  is  new  POWERIRATIONAL.  “♦'); 

We  next  consider  a variation  of  the  previous  generic  function  in  which  a unary  function  is  applied 
repeatedly: 

generic!  type  T; 

function  NEXT(X  : T)  return  T) 
function  INVOLUTIONS  : T;  N : NATURAL)  return  T is 
RESULT  : T :=  A; 
begin 

for  I in  1 ..  N loop 

RESULT  :=  NEXT(RESULT); 
end  loop; 
return  RESULT: 
end  INVOLUTION: 

This  generic  function  can  be  used  to  apply  any  unary  function  repeatedly,  for  example,  to  produce 
the  nth  successor  or  predecessor  of  an  enumeration  value 

function  SUCC  is  new  INVOLUTIONICOLOR.  COLOR  SUCC); 
function  PRED  is  new  INVOLUTIONICOLOR,  COLOR  PRED), 

Again,  these  declarations  produce  functions  whose  specifications  are  equivalent  to 

function  SUCC  (A  : COLOR;  N : NATURAL)  return  COLOR; 
function  PRED  (A  : COLOR;  N : NATURAL)  return  COLOR; 

Similar  functions  can  be  instantiated  to  find  the  nth  successor  or  predecessor  of  an  item  in  a list: 
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function  SUCC  (X  : USTJTEM)  return  USTJTEM  la 
begin 

return  X.SUCC: 


and; 

function  PRED(X  : LISTJTEM)  ratum  USTJTEM  it 

bagin 

ratum  X.PRED; 
and: 


function  SUCC  ia  naw  INVOLUTION(LIST_ITEM.  SUCC): 
function  PRED  ia  naw  INVOLUTIONILISTJTEM.  PRED); 

1 1 

Note  that  these  involutions  overload  (but  do  not  hide)  the  functions  SUCC  and  PRED  Actually,  the 
immediate  successor  of  an  element  can  be  obtained  in  three  ways: 

X.SUCC  — using  the  component  SUCC 

SUCC(X)  — the  unary  function 

SUCC(X.I)  --  the  involution 


13.3.2  An  Example  of  a Generic  Package 


A discussion  of  generics  would  probably  not  be  complete  without  a presentation  of  the  treatment 
of  either  stacks  or  queues.  Since  the  example  of  stacks  has  already  been  given  in  the  Green 
Reference  Manual,  we  shall  give  here  a formulation  of  queues. 


The  specification  of  the  generic  package  contains  two  generic  parameters  : ITEM,  the  type  of  the 
items  in  the  queue,  and  SIZE,  the  size  of  each  queue. 


generic(t,pe  ITEM;  SIZE  : NATURAL) 
package  ANY_QUEUE  ia 

restricted  type  QUEUE  is  private; 

function  EMPTY  (Q  : in  QUEUE)  return  BOOLEAN, 

procedure  ADD  (X  : in  ITEM;  Q : in  out  QUEUE): 

procedure  REMOVE  (Q  ; in  out  QUEUE); 

function  FRONT  (Q  : in  QUEUE)  return  ITEM; 

QUEUEJDVERFLOW,  QUEUE  JJNDERFLOW  : exception; 
private 

type  QUEUE  is 
record 

STORE  ; array  (1  ..  SIZE)  of  ITEM; 

COUNT  : INTEGER  range  0 ..  SIZE  :=  0: 

INJNDEX  : INTEGER  range  1 ..  SIZE  :=  1; 
OUTJNDEX  : INTEGER  range  1 ..  SIZE  ;=  1; 

and  record; 

and: 


The  package  bod  / provides  the  bodies  of  the  functions  and  procedures  promised  in  the  specifica- 
tion. ^ 


package  body  ANY_QUEUE  it 

function  EMPTY(Q  : in  QUEUE)  ratum  BOOLEAN  is 
begin 

ratum  Q.COUNT  = 0; 
end  EMPTY; 

procedure  ADD(X  : in  ITEM;  Q:  in  out  QUEUE)  it 

begin 

if  Q.COUNT  < SIZE  then 
Q.STORE(Q.INJNDEX)  ;=  X; 

Q.INJNDEX  :=  (Q.INJNOEX  mod  SIZE)  +•  1; 

Q.COUNT  :=  Q.COUNT  +1; 

else 

raise  QUEUE_OVERFLOW; 
end  if; 
end  ADD; 

procedure  REM0VE(Q  : in  out  QUEUE)  it 
begin 

if  Q.COUNT  > 0 then 

Q.OUTJNDEX  :=  (Q.OUTJNDEX  mod  SIZE)  + 1; 

Q.COUNT  :=  Q.COUNT  - 1; 

else 

raise  QUEUEJJNDERFLOW; 
end  if; 

end  REMOVE; 

function  FRONT(Q  : in  QUEUE)  return  ITEM  is 
begin 

if  Q.COUNT  > 0 then 

return  Q.STORE(Q.OUTJNDEX); 

else 

raise  QUEUE_UNDERF10W; 
end  if; 
end  FRONT; 

end  ANY_QUEUE; 

Having  defined  ANY_QUEUE,  it  is  now  possible  to  instantiate  two  packages  dealing  respectively 
with  queues  of  integers  and  queues  of  reals: 

package  ANY_INT_QUEUE  is  new  ANY_QUEUE(ELEM  is  INTEGER.  SIZE  :=  100)' 
package  ANY_REAL_QUEUE  is  new  ANY_QUEUE(ELEM  is  REAL,  SIZE  :=  100); 

Semantically,  these  two  declarations  have  created  two  packages  which  may  be  used  as  ordinary 
packages.  In  the  present  case,  given  that  the  same  value  has  been  given  for  SIZE,  the  translator 
may  be  able  to  reuse  the  same  code  for  the  procedures  of  the  two  modules,  if  reals  and  integers 
occupy  the  same  number  of  bits. 
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A block  dealing  with  real  queues  may  appear  as  below: 

declare 

use  ANY_REAL_QUEUE; 

QA.  QB  : QUEUE: 

begin 

ADDI3.14,  QA): 

M FRONT(QA)  = FRONT(QB)  then 
REMOVE(QA); 

ADD(FRONT(QB)  + 1.0.  QA); 

end  if; 

end; 

With  the  use  clause  for  ANY_REAL_QUEUE,  the  type  QUEUE  is  visible  and  can  be  used  to  declare 
the  queues  of  reals  QA  and  QB 

A slight  difficulty  exists  if  one  wants  to  use  both  ANY_REAL_QUEUE  and  ANY_INT_QUEUE  in  the 
same  scope,  since  both  declare  the  type  QUEUE.  The  naming  conflict  is  resolved  by  naming  the 
type  as  a selected  component: 

declare 

use  ANY_REALQUEUE,  ANYJNT_QUEUE; 

QA  : ANY_REALQUEUE. QUEUE; 

QJ  : ANYJNT.QUEUE.QUEUE; 

begin 

ADD(3.0E5.  QA); 

REMOVE(QJ); 

ADDI15,  QJ); 

end; 

Generally,  using  selected  components  for  the  names  of  types  will  be  sufficient  (their  repeated  use 
can  be  avoided  by  declaring  corresponding  subtypes).  Thereafter  functions  and  procedures  (such 
as  ADD)  appear  as  overloaded  subprograms  and  no  confusion  is  possible.  For  example  the 
expanded  specifications  of  ADD  are  equivalent  to 

procedure  ADD(X  : in  REAL;  Q : in  out  ANY_REALQUEUE. QUEUE); 

procedure  ADD(X  : in  INTEGER;  Q : in  out  ANYJNT.QUEUE.QUEUE); 

In  the  case  of  the  exceptions  QUEUE_0VERFL0W  and  QUEUE_UNDERFLOW  overloading  is  of 
no  help  and  either  selected  components  or  renaming  declarations  must  be  used. 

A final  word  on  these  two  exceptions:  the  bodies  of  ADD,  REMOVE  and  FRONT  have  been  written 
so  that  no  damage  occurs  to  the  queue  if  either  exception  occurs.  As  a consequence  it  is  possible 
to  provide  a local  handler  for  these  exceptions: 
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declare 

use  ANY_REAL_QUEUE.  ANYJNT_QUEUE; 

subtype  INT_QUEUE  is  ANYJNT_QUEUE.QUEUE;  - INT_QUEUE  defined  bs  an  abbreviation 
INTQ_ERROR  : exception  renames  ANY_INT_QUEUE.QUEUE_OVERPLOW- 
QJ  : INT_QUEUE; 


ADD(3,  QJ); 

exception 

when  INTCL.ERROR  => 

- actions  that  will  terminate  the  execution  of  the  block  in  case  QJ  overflows. 

end; 


13.3.3  An  Example  of  a Generic  Task 


As  a further  example  consider  the  buffering  interposed  between  a producer  and  a consumer  (see 
the  example  of  section  9. 1 2 of  the  reference  manual).  This  might  be  reformulated  as  a generic  task 
where  the  type  of  the  buffered  items  as  well  as  the  size  of  the  buffer  in  question  have  been  fac- 
tored out  as  generic  parameters. 

gansricltype  ITEM;  SIZE  : INTEGER  :=  100) 

task  BUFFERING  is 

entry  READ  (C  : out  ITEM); 
entry  WRITE  (C  : in  ITEM); 

end; 

task  body  BUFFERING  is 


J W wi  I kl  IMXXJ  ie 

POOL  : array!  1 ..  SIZE)  of  ITEM; 

COUNT  : INTEGER  range  0 ..  SIZE  :=  0; 
INJNDEX,  OUTJNDEX  : INTEGER  range  1 

oin 


..  SIZE  := 


when  COUNT  < SIZE  => 

accept  WRITEIC  : in  ITEM)  do 
POOL(IN_INDEX)  :=  C; 

end; 

INJNDEX  :=  (INJNDEX  mod  SIZE)  + 1; 
COUNT  COUNT  + 1; 

or 

when  COUNT  > 0 => 

accept  READ(C  : out  ITEM)  do 
C :=  POOL(OUTJNDEX); 

end; 

OUTJNDEX  :=  (OUTJNDEX  mod  SIZE)  + 1; 
COUNT  ;=  COUNT  - 1; 

and  select; 
end  loop; 
end  BUFFER; 


A task  equivalent  to  that  given  in  the  reference  manual  is  obtained  by  the  generic  instantiation 
task  BUFFER  is  nm  BUFFERING(CHARACTER); 

Use  of  the  generic  formulation  permits  the  same  strategy  to  be  employed  in  a variety  of  different 
applications,  for  example: 

task  MESSAGE_BUFFER  is  new  BUFFERINGdTEM  is  MESSAGE,  SIZE  :=  BACKLOG); 

where  MESSAGE  is  assumed  to  be  a previously  declared  type  and  BACKLOG  is  some  function 
which  estimates  a reasonable  size  for  the  buffer. 

It  is  interesting  to  observe  that  the  logic  of  the  queuing  strategy,  shown  by  the  example  in  the 
previous  section,  and  that  of  the  buffering  strategy,  presented  above,  are  in  many  respects  iden- 
tical. The  essential  difference  between  the  two  approaches  is  that  overflow  and  underflow  are 
treated  as  exceptions  in  the  former  case,  whereas  in  the  latter  case  they  merely  result  in  some 
parallel  task  waiting  until  it  can  proceed. 


13.3.4  A Mora  Complicated  Example 


A final  example,  involving  binary  trees,  is  presented  to  illustrate  the  use  of  different  kinds  of  generic 
program  units  in  combination.  A frequently  encountered  data  type  like  binary  trees  is  best  encap- 
sulated within  a package,  where  the  types  of  the  leaves  and  nodes  can  be  factored  out  as  generic 
parameters.  A straightforward  definition  of  the  (recursive)  data  structure  in  question  might  then  be 
formulated  as  follows: 

generic  (type  LEAFJTYPE; 

type  NODE_TYPE) 
package  BINARY. TREES  Is 

type  TREE  is  access 
record 

KIND  : constantlLEAF,  NODE); 
case  KIND  of 
when  LEAF  => 

LVAL  : LEAF.TYPE; 
when  NODE  => 

NVAL  : NODE_TYPE; 

LEFT  : TREE; 

RIGHT  : TREE; 
end  case; 
end  rs rd; 

--  specifications  of  standard  operations  on  binary  trees 
end  BINARY_TREES; 

A number  of  standard  operations  associated  with  binary  trees  would  normally  be  included  within 
the  generic  definition  module  given  above;  for  simplicity  they  will  not  be  detailed  here.  Instead  we 
will  illustrate  the  typical  ways  in  which  binary  trees  are  processed.  These  generally  involve  a recur- 
sive traversal  (or  walk I of  the  tree  in  one  of  a few  characteristic  orders  (e.g.,  prefix  order,  infix  order, 
O'-  postfix  order).  These  orders  can  be  expressed  as  generic  operations. 
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The  most  common  of  these  orders  is  used  in  the  example  below  This  is  the  postfix  walk,  where  a 
certain  operation  is  applied  to  each  leaf  while  another  operation  is  applied  to  each  node  as  well  as 
to  the  results  of  previously  processed  left  and  right  branches.  The  desired  generic  function  miqht 
be  defined  (within  the  BINARY_TREES  module)  as  y 


generic!  type  RESULT  : 

function  LEAF_OP  (L 
function  NODE_OP  IN  : NODE_TYPE;  L 
function  POS?T_WALK(T  : TREE)  return  RESULT 
begin 

case  T KIND  o* 
when  LEAF  => 

return  LEAF_OP|T.LVAL) 
when  NODE  => 
declare 

LB  : constant  RESULT 
RB  : constant  RESULT 
begin 

return  NODE_OP(T.NVAL.  LB  RB); 

end 
end  case 

end  POST..WALK; 


LEAF_TYPE)  return  RESULT 

R : RESULT)  return  RESULT) 
is 


;=  POST_WALK(T.LEFT): 

= POST_WALK(T.  RIGHT'; 


Note  that  the  re  'ursive  invocations  of  POST_WALK  within  this  function  cause  no  confusion  tor 
infinite  loop  during  instantiation)  since  the  name  of  the  generic  function  taken  always  refers  to  the 
same  instantiation. 

A number  of  useful  utility  functions  on  binary  trees  follow  the  pattern  of  a postfix  walk.  Some  of 
these  might  well  be  included  within  the  module  BINARY  .TREES  it . elf.  For  example.  COUNT 
DEPTH  and  WIDTH  (given  appropriate  definitions  of  the  function  ONE  matching  LEAF_OP  and  of 
the  functions  SUM.  SUM_PLUS_ONE  and  MAX.  matching  NODE_OP)  are  instantiated  by  the 
declarations 


function  COUNT  is 

nsw  POL  i_WALK(RESULT  is  INTEGER  LEAF_OP  is  ONE.  NODE.OP  is  SUM_PLUS_ONE) 
function  DEPTH  is 

nsw  POST_WALK( RESULT  is  INTEGER.  LEAF.OP  is  ONE  NODE_OP  is  MAX); 
function  WIDTH  is 

nsw  POST.WALKIRESULT  is  INTEGER.  LEAF.OP  is  ONE.  NODE_OP  is  SUM) 

The  advantages  of  using  the  generic  facility  in  this  fashion  to  formulate  a basic  pattern  for  several 
similar  definitions  are  obvious.  Another  application  of  such  definitions  involves  the  use  of  binary 
trees  to  represent  simple  arithmetic  expressions,  where  the  leaves  are  integer  values  and  the 
nodes  corresponu  to  the  usual  operators: 

typo  OPERATOR  is  (ADD.  SUB,  MUL,  DIV); 

The  appropriate  definition  can  be  obtained  by  instantiating  the  generic  package 

package  EXPR.TREES  is 

now  BINARY_TREES(LEAF_TYPE  is  INTEGER,  NODE_TYPE  is  OPERATOR): 
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In  an  application,  n use  clause  would  be  provided  for  this  package  and.  tor  convenience,  the  tree 
type  would  bo  renamed  by  a subtype  declaration: 


use  EXPR  TREES: 

subtype  EXPR  is  EXPR  TREES.TREE: 

One  may  then  introduce  the  specific  operations  associated  with  the  type  of  tree  in  question.  The 
most  obvious  is  the  evaluation  function 

function  EVALIE  : EXPR)  return  INTEGER 

This,  however,  exactly  follows  the  pattern  of  a postfix  walk,  and  may  therefore  be  directly  obtained 
by  instantiation 

function  EVAL  is 

new  POST.WALKiRESULT  is  INTEGER.  LEAF  .OP  Is  VALUE.  NODE.  OP  is  INTERPRET); 

where  the  requisite  definitions  of  VALUE  and  INTERPRET  are  as  follows: 

function  VALUED  : INTEGER)  return  INTEGER  Is 
pragma  INLINE: 

begin 
return  I; 
and; 

function  INTERPRETIOP  OPERATOR;  L.  R INTEGER)  return  INTEGER  la 
pragma  INLINE: 
begin 

case  OP  of 

when  ADD  > return  L + R; 

when  SUB  »>  return  L R. 

when  MUL  »>  return  L ♦ R; 

when  DIV  return  I / R; 

end  cose; 

end; 

Once  again,  the  desired  function  is  obtained  by  merely  providing  the  appropriate  operations  tor 
each  leaf  and  node,  while  the  details  of  the  recursive  treewalk  are  encapsulated  within  the  generic 
function  POST_WALK. 

The  binary  tree  example  of  this  subsection  presents  a rather  sophisticated  structure,  namely  a 
generic  recursive  function  (the  function  is  recursive  but  there  is  of  course  no  recursive  instantia 
tion)  the  declaration  of  which  is  itself  nested  within  a generic  package'  While  this  example  shows 
why  such  complicated  formulations  are  occasionally  desirable  (see  also  |VH  751),  a word  of  warn- 
ing is  in  order,  particularly  with  regard  to  generic  modules  Dependency  between  generic  modules 
m the  form  of  mutual  instantiation  is  not  allowed  since  such  a structure  would  yield  an  infinite  loop 
during  instantiation: 


1 


I 
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generic!) 
package  A it 

and; 


M 


generic!) 

package  B it 


package  body  A it 

package  NEW_B  it  new  B(...);  ~ EITHER  THIS  IS  I LLEGAL 1 1 1 

end  A; 

package  body  B it 

package  NEW_A  it  new  A(...»;  - OR  THIS  IS  ILLEGAL!!! 

end  B; 


13.4  Rationale  for  the  Formulation  of  Generics 


Several  simplifications  have  been  adopted  in  the  design  of  a generic  facility.  Naturally  when  atten- 
tion is  focused  on  any  given  language  feature,  there  is  a tendency  to  believe  that  it  is  the  most 
important  feature.  On  the  other  hand,  when  trying  to  integrate  such  a feature  into  a language,  one 
must  take  care  not  to  make  its  impact  on  the  language  larger  than  its  real  importance  to  the  user. 
This  general  argument  applies  particularly  to  generics.  A generic  facility  is  certainly  useful,  but  its 
inclusion  in  the  language  should  not  be  done  at  the  expense  of  other  important  criteria,  such  as 
reliability,  efficiency,  and  above  all,  simplicity  of  use. 

The  generic  facility  is  expected  to  serve  for  the  construction  of  general  purpose  parameterized 
packages.  Whereas  such  packages  are  likely  to  be  utilized  by  large  classes  of  users,  it  should  be 
realized  that  relatively  few  users  will  actually  be  involved  in  writing  generic  packages.  Accordingly, 
we  have  tried  to  design  a facility  that  can  almost  be  ignored  by  the  vast  majority  of  users.  They 
must  indeed  know  how  to  instantiate  a generic  package  and  this  is  fairly  easy.  On  the  other  hand, 
they  need  not  be  familiar  with  the  rules  and  precautions  necessary  for  writing  generic  program 
units. 

A major  simplification,  in  this  respect,  is  achieved  by  adopting  an  approach  based  on  a context 
dependent  extension  of  the  traditional  techniques  of  macro-expansion,  in  preference  to  more  com- 
plex facilities  such  as  mechanisms  for  parameterization  of  data  types.  This  solution  has  the  advan- 
tage of  introducing  only  minimal  extensions  to  the  language  and  its  translators,  and  it  is  well 
implementable  within  the  state  of  the  art.  It  does  not  complicate  the  concept  of  type  as  perceived 
by  the  vast  majority  of  users,  and  it  nevertheless  provides  the  flexibility  required  by  the  applica- 
tions. 

The  goal  of  simplicity  of  use  stated  above  has  important  consequences  on  the  specification  of  for- 
mal generic  parameters.  The  other  major  simplifying  assumptions  made  in  this  language  are  the 
absence  of  any  implicit  derivation  of  attributes  of  type  parameters  (although  default  attributes  can 
be  specified),  and  similarly  the  absence  of  any  implicit  instantiation  of  generic  program  units. 
These  issues  will  be  discussed  separately  below. 
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1 3.4.1  Explicit  Instantiation  of  Ganaric  Program  Units 


An  important  simplification  for  the  translation  of  program  units  obtained  by  generic  instantiation  is 
the  requirement  that  such  instantiation  be  explicit. 

The  approach  taken  here  clearly  distinguishes  between  the  instantiation  of  a program  unit  derived 
from  a generic  program  unit,  and  the  invocation  of  a unit  (calling  a subprogram,  using  a module). 
Thereby  it  emphasizes  the  difference  between  translation  time  substitutions  of  generic  parameters 
and  execution  time  passage  of  actual  parameters  to  subprograms.  This  provides  a well-defined 
locus  for  the  point  of  instantiation  (and  for  reporting  any  errors  arising  from  inconsistent  sub- 
stitution) while  permitting  the  resultant  program  unit  to  be  subsequently  invoked  as  often  as 
required,  with  the  same  degree  of  power  and  security  as  for  any  other  non-generic  program  unit. 
This  is  a consequence  of  the  fact  that,  once  a generic  declaration  has  been  instantiated,  the  par- 
ticular instance  is  indistinguishable  from  a simitar  program  unit  defined  explicitly  at  the  point  of 
instantiation. 

An  alternate  solution  considered  was  implicit  instantiation.  For  the  purpose  of  the  discussion  of  the 
complexity  of  implicit  instantiation,  consider  the  following  generic  function  (which  is  actually  just  a 
different  way  of  writing  the  power  function  in  section  13.3.1): 

generic!  type  T; 

function  "*"  (X,  Y : T)  return  T); 
function  "**'  (A:  T;  N : NATURAL)  return  T it 
begin 

if  N = 1 then 
return  A; 

else 

return  A * A**(N-1); 
end  if; 
end 

If  implicit  instantiation  were  provided  then  for 

R : RATIONAL; 

I : INTEGER; 

exponentiation  could  be  applied  without  prior  explicit  instantiation.  Thus 

R**5 

1**5 

would  both  be  legal.  The  actual  type  used  for  T would  have  to  be  implicitly  derived  from  the  actual 
argument  supplied  for  A (that  is,  RATIONAL  for  R,  INTEGER  for  I). 

It  is  quite  clear  that  implicit  instantiation  would  considerably  complicate  the  algorithm  used  for 
identification  of  overloaded  subprograms.  For  example,  **  would  be  an  overloading  in  the 
RATIONAL  case  whereas  it  would  be  a redefinition  of  predefined  exponentiation  in  the  INTEGER 
case.  Moreover  if  the  programmer  had  defined  his  own  version  of  **  within  the  package 
RATIONALJMUMBERS  itself,  for  example: 

function  “**•  (A  : RATIONAL;  N : INTEGER)  return  RATIONAL; 

then  this  explicit  definition  would  hide  the  generic  definition  in  an  application  such  as  R**5.  Thus 
the  generic  definition  would  be  visible  for  some  types  and  hidden  fo.  others. 
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Another  problem  arises  for  the  correct  identification  of  **  in  the  body  of  the  generic  unit  itself:  is  it 
a recursive  implicit  instantiation  or  a recursive  call  of  the  same  instance?  In  the  simple  example 
considered,  it  could  easily  be  concluded  that  it  is  a recursive  call.  However,  in  general,  it  is  not  8t 
all  clear  that  the  problem  can  always  be  resolved  by  a static  analysis  of  the  program  (unless  restric 
tions  are  adopted).  A sufficient  condition  to  guarantee  that  no  generic  operation  will  ever  require 
an  unbounded  number  of  implicit  generic  instantiations  during  execution  has  been  given  in  IB J 
781  However  such  checks  require  a quite  complex  analysis  of  the  program. 

In  conclusion,  we  consider  implicit  Instantiation  as  a major  research  subject  at  this  date  (1979). 
The  only  solution  within  the  current  state  of  the  art  is  explicit  instantiation  and  this  is  hence  the 
solution  chosen  for  this  language 

Explicit  instantiation  certainly  requires  more  writing  on  the  part  of  the  user,  but  this  has  the  effect 
of  making  him  aware  of  what  he  is  actually  doing  and  thus  contributes  to  reliability  and  readability 
In  addition,  it  offers  distinct  advantages  in  terms  of  efficiency,  since  the  translator  can  easily  iden- 
tify the  existing  instantiations  and,  in  some  cases,  perform  optimizations  such  as  the  sharing  of 
code  for  dosed  procedures. 


13.4.2  Specification  of  Formal  Generic  Parameters 


As  stated  earlier,  it  should  be  possible  for  a user  instantiating  a given  generic  package  to  complete- 
ly ignore  the  internal  details  of  this  generic  unit.  In  particular  if  any  error  is  made  in  instantiating  a 
generic  unit,  it  should  be  reported  to  the  user  in  terms  of  the  generic  instantiation  itself  and  not  in 
terms  of  the  internals  of  the  generic  unit.  This  requirement  has  consequences  on  the  form  used  for 
specifying  formal  generic  parameters 

By  analogy  consider  what  is  done  for  subprograms.  For  a normal  (that  is,  non-generic)  procedure, 
specification  of  parameters  enables  independent  checks  of  the  procedure  body  on  the  one  hand 
and  of  the  procedure  calls  on  the  other  hand.  Both  must  conform  to  the  formal  parameter 
spec  ‘ications  and  these  conformity  checks  can  be  done  independently. 

The  specification  of  generic  parameters  provided  by  a generic  clause  must  enable  the  same  degree 
of  independence. 

(a)  It  should  be  possible  to  check  that  the  text  of  the  generic  body  is  consistent  with  respect  to 
the  parameter  specifications. 

(b)  For  a given  generic  instantiation,  it  should  be  possible  to  check  that  the  actual  parameters 
conform  to  those  specifications. 

(c)  The  precision  of  the  specifications  should  be  sufficient  to  guarantee  that  if  (a)  is  satisfied  then 
any  instantiation  (b)  will  produce  a semantically  correct  expanded  prognm  unit. 

The  solution  adopted  achieves  these  goals  in  a simple  manner.  For  a type  specified  as  restricted  in 
a generic  clause,  no  operation  on  the  type  is  assumed  available.  For  other  types,  only  assignment 
and  the  predefined  comparison  for  equality  or  inequality  are  available.  Hence  a formal  parameter 
that  is  a type  is  considered  as  a private  type  within  the  generic  unit.  Any  operation  (apart  from  the 
above  mentioned  predefined  operations)  applied  to  objects  of  the  type  within  the  generic  unit  must 
be  supplied  as  an  additional  generic  parameter. 
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When  checking  the  body  of  the  generic  unit,  the  generic  clause  thus  provides  the  information 
required  for  the  identification  of  ail  operators.  When  checking  a given  instantiation,  it  must  match 
the  generic  clause  and  incorrect  actual  parameters  can  be  reported.  These  two  checks  can  be  per- 
formed independently. 

As  an  example  consider  the  generic  clause  given  for  the  function  POWER: 


i 

A 


generic  ( type  T; 

function  (X,  Y : T)  return  T) 
function  POWER! A : T;  N : NATURAL)  return  T it 
begin 

if  N = 1 then 
return  A; 

else 

return  A*POWER(A.  N-1): 

end  if; 
end  POWER; 

The  operation  * is  explicitly  provided  as  a generic  parameter  as  well  as  the  type  T itself.  The 
parameter  A and  the  result  of  the  function  POWER  are  both  specified  as  being  of  this  formal  type. 
Thereafter  the  identification  of  the  * appearing  within  the  generic  body  in  A*PO'VER(A,  N-1)  can 
be  done  as  usual;  it  refers  to  the  * declared  in  the  generic  clause.  Similarly  (implicit  instantiation 
being  impossible)  the  recursive  call  of  POWER  can  be  correctly  identified.  Hence  the  generic  body 
can  be  completely  checked. 

Similarly  a generic  instantiation  such  as 

function  "**"  is  new  POWER! RATIONAL,  "*"); 


can  be  fully  checked.  It  is  correct  if  there  exists  an  operation  'V  on  the  tv^e  RATIONAL.  The 
specification  of  this  operation  corresponds  to 


function  (X.  Y : RATIONAL)  return  RATIONAL; 

hence  it  matches  the  specification  of  the  generic  formal  parameter.  Conversely  consider 

function  “**•  is  new  P L WERIRATIONAL  "not");  - ILLEGALI 

This  generic  instantiation  can  be  reported  as  incorrect  since  there  is  no  operation  not  cor- 
responding to  the  specification 

function  "not"  (X.  Y : RATIONAL)  return  RATIONAL;  - ILLEGALI 

An  alternative  considered  in  this  design  was  the  implicit  derivation  of  operations  that  are  attributes 
of  a generic  type.  The  reasons  for  rejecting  this  alternative  are  similar  to  those  leading  to  the  rejec- 
tion of  implicit  instantiation.  If  implicit  derivation  of  attributes  were  allowed,  the  previous  example 
could  be  rewritten  with  the  generic  clause 

gsnsricltyps  T) 

and  we  would  be  left  with  the  problem  of  identifying  the  * operation  used  in  the  body.  For  a given 
instantiation,  say  with  the  type  RATIONAL,  shot  Id  the  * operation  be  identified  as  a global  opera- 
tion in  the  context  of  the  generic  declaration  or  in  the  context  of  the  generic  instantiation?  The  two 
alternatives  may  lead  to  different  results. 
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Note  also  that  the  identification  may  be  ambiguous  ince  both 

function  (X.  Y RATIONAL)  return  RATIONAL; 

function  V (X  RATIONAL;  Y INTEGER)  return  RATIONAL; 

would  he  acceptable  in  the  absence  of  a specification  for  the  formal  operation  *. 

In  general,  the  specifications  of  the  identified  operations  could  be  quite  different  from  instantiation 
to  instantiation  depending  on  the  operations  visible  in  the  context  of  the  instantiation.  This  could 
happen  even  if  the  type  parameter  is  the  same.  As  an  example  consider  the  expression  A«(B/C) 
where  A.  B and  C are  of  type  RATIONAL  and  where  / is  declared  to  deliver  a result  of  type 
RATIONAL  in  one  context  and  of  type  INTEGER  in  another  context. 

To  summarize,  implicit  derivation  of  attributes  would  introduce  an  awkward  context  dependence 
and  would  requite  a complete  checking  of  the  generic  body  for  each  instantiation.  This  last  conse- 
quence would  be  particularly  unfortunate,  since  generic  bodies  could  not  be  checked  and  proved 
correct  independently  of  the  context  It  would  defeat  the  goal  stated  initially,  since  some  error 
messages  would  have  to  be  stated  in  terms  of  what  is  done  within  the  generic  body. 

For  these  reasons  we  have  retained  the  solution  of  explicit  specification  of  all  operations  that  are 
used  on  objects  of  a formal  type.  This  solution  permits  independent  checking  of  generic  units  and 
of  generic  instantiations  Hence  it  fulfills  our  goal  of  permitting  the  user  to  ignore  the  internal 
details  of  the  generic  units  instantiated  in  his  programs. 


13.4.3  Default  Generic  Parameters 


As  stated  before,  all  operations  applicable  to  a formal  type  must  be  specified  explicitly  in  the 
gene,  c clause.  Nevertheless  in  order  to  keep  generic  instantiations  as  simple  as  possible,  a facility 
for  specifying  default  values  for  generic  parameters  is  offered,  as  for  normal  subprograms. 

In  many  cases,  such  default  values  will  actually  be  expressed  as  attributes  (predefined  or  not)  of 
the  formal  type.  For  example  the  generic  clause  of  the  function  POWER  can  be  rewritten  as  fol- 
lows; 

generic!  type  T; 

function  (X.  Y : T)  return  T is  T-*-) 

specifying  T."*",  the  * attribute  of  the  type  T,  as  the  default  to  be  used  in  the  absence  of  an  explicit 
actual  parameter.  This  parallels  exactly  the  treatment  of  in  parameters  with  default  values  for  sub- 
programs. The  default  parameter  is  optional  and  an  instantiation  such  as 

function  -.*-  is  nrw  POWER(HATIONAL); 

is  taken  as  equivalent  to  the  generic  instantiation 

function  *.»"  is  nsw  POWER  (RATIONAL.  RATIONAL.-*'); 

or  to  the  generic  instantiation 


function  is  new  POWERI RATIONAL. 


This  produces  a valid  declaration  since  * is  defined  for  RATIONAL.  For  the  same  reason 


1 


function  "*»"  is  new  POWER(BOOLEAN); 

is  an  error  since  BOOLEAN."*"  is  meaningless  (unless  of  course  * were  overloaded  for 
BOOLEAN!). 


Again,  the  generic  body  and  the  generic  instantiations  can  be  checked  independently.  Further- 
more. the  default  can  always  be  overriden  by  providing  an  explicit  parameter  as  in 


function  "**'  it  mw  POWER(VECTOR.  MULT); 


Default  attributes  may  conveniently  be  used  to  treat  a type  parameter  as  if  it  were  a discrete  type 
by  providing  the  corresponding  one  to  one  mappings  to  the  integers.  Consider  a unit  that  has  a 
generic  clause  like 


generic!  typo  DISCRETE; 

FIRST  : DISCRETE  :=  DISCRETE  FIRST: 

LAST  : DISCRETE  :=  DISCRETELAST; 

function  ORDINALIX  : DISCRETE)  return  INTEGER  it  DISCRETEORD: 
function  VALUE(Y  : INTEGER)  return  DISCRETE  it  DISCRETE  VAL) 

peckege  P it 


end; 

The  integer  equivalents  of  the  values  of  type  DISCRETE  can  always  be  used  by  applying  ORDINAL 
and  VALUE,  for  example,  whenever  a discrete  range  is  required  in  loops,  and  so  on.  The  package  P 
can  be  instantiated  for  discrete  types  with  a default  derivation  of  attributes: 


now  P(CHARACTER) 


Note  finally  that  it  nay  also  be  instantiated  for  a type  T that  is  not  discrete. 

new  P(T,  FIRST_T,  LAST_T.  T_TO_INTEGER.  INTEGER_TO_T) 
with  appropriately  defined  functions. 


To  summarize,  the  necessity  to  be  able  to  check  a generic  body  independently  of  its  generic  instan- 
tiations (an  important  user  requirement)  lead  us  to  specify  explicitly  a>l  operations  applicable  to  a 
formal  type  in  the  generic  clause.  This  has  the  effect  of  increasing  the  number  of  generic 
parameters  that  must  be  supplied  and  could  hence  lead  to  a heavy  syntax  of  generic  instantiations. 
However,  one  can  specify  default  values  for  these  operations,  thus  restoring  the  simplicity  of 
generic  instantiations. 


In  most  applications,  it  should  be  possible  to  have  only  types  as  mandatory  parameters  and  to 
provide  default  values  for  all  operations.  An  example  of  such  application  is  given  by  the  generic 
input  output  package  defined  in  chapter  14  of  the  Reference  Manual.  In  the  design  of  such  a 
package  it  was  vital  to  be  able  to  simplify  the  instantiation  (what  the  user  needs  to  do)  to  the 
extreme.  This  has  been  achieved  by  providing  default  values  for  all  generic  parameters  except,  of 
courso.  for  the  type  for  which  the  package  is  instantiated.  This  is  consistent  with  the  goal  stated  in 
the  introduction:  writing  a generic  unit  may  well  require  some  care;  using  it.  on  the  other  hand, 
should  be  extremely  simple. 
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14.  Representation  Specifications  and  Machine  Dependencies 


There  is  an  inherent  dilemma  in  the  design  of  a high  order  language  with  a system  programming 
capability.  On  the  one  hand  we  are  trying  to  achieve  reliability  by  raising  the  level  of  the  language. 
For  example  we  provide  data  types  and  encourage  the  use  of  an  abstract  view  of  objects  in  which 
they  are  known  only  by  the  set  of  operations  applicable  to  them.  Controlling  the  applicable  opera- 
tions enables  the  detection  of  incorrect  usage. 

On  the  other  hand,  system  applications  require  the  ability  to  stay  rather  close  to  the  machine,  and 
not  only  for  efficiency  reasons.  For  example,  defining  a hardware  description  must  be  done  in 
terms  of  the  physical  properties,  the  bit  positions,  etc.  A mapping  different  from  that  prescribed  by 
the  hardware  would  be  not  only  inefficient,  but  also  incorrect  and  would  not  work  at  all.  To 
produce  a correct  program  in  such  cases  we  are  forced  to  abandon  the  abstract  view  and  to  work 
in  terms  of  the  physical  representation.  This  contradiction  cannot  be  avoided;  the  language  must 
permit  dealing  with  objects  at  two  different  levels,  the  logical  and  the  representational  levei. 

Clearly,  dealing  with  physical  representations  is  inherently  dangerous.  However,  some  control  can 
still  be  achieved  if  the  language  enforces  a clear  separation  of  the  logical  properties  and  their 
representation. 

This  separation  principle  is  discussed  below,  along  with  the  problem  of  changing  representation 
and  with  the  analysis  of  the  issues  raised  by  the  different  forms  of  representation  specifications 
available  in  the  language.  This  chapter  also  covers  the  means  to  specify  the  parameters  of  a con- 
figuration and  their  counterpart,  environment  enquiries.  Finally,  we  present  the  means  available  for 
interfacing  with  other  languages. 


14.1  The  Separation  Principle 


Several  languages  have  already  adopted  the  principle  of  separation  of  logical  properties  from 
representational  properties.  We  may  summarize  this  principle  as  follows: 

Data  type  definitions  are  made  in  two  steps: 

(1 ) First,  the  logical  properties  of  data  are  defined.  They  describe  all  the  behavioral  properties  that 
programmers  need  to  know.  All  algorithms  are  formulated  in  terms  of  these  logical  properties 
and  are  not  based  on  knowledge  of  the  representation. 

(2)  Second,  the  representation  (implementation)  properties  of  data  may  either  be  explicitly 
specified  by  the  programmer  or,  in  the  usual  case,  chosen  by  default  by  the  translator. 

There  are  many  advantages  to  such  a separation.  The  most  fundamental  is  the  conceptual 
simplicity  of  formulating  an  algorithm  in  terms  of  abstract  objects;  the  ability  to  abstract  from  a 
particular  representation  leads  to  clearer  and  better  structured  programs. 

I o 
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To  certify  correctness  of  a program  working  with  data  D and  representation  R,  we  have  two 
disjoint  proofs.  First  we  show  that  the  program  is  correct  given  the  definition  of  D.  Then  we  show 
that  R is  a correct  implementation  of  D.  Such  a separation  also  ensures  that  users  do  not  make 
hidden  assumptions  about  the  representational  properties  of  data. 

If  at  a later  stage  an  alternate  representation  is  used  for  the  data,  for  instance  for  minimization  of 
storage  space,  the  formulation  of  the  algorithms  need  not  be  modified.  Conversely,  when  the 
algorithmic  part  of  a program  is  modified,  only  the  algorithm  proof  needs  to  be  redone. 

Another  advantage  is  textual  simplicity.  In  some  cases,  the  representation  of  a data  type  may  be 
dictated  by  extern., I considerations  such  as  the  form  of  a hardware  interface.  The  description  of  the 
representation  may  then  have  a complexity  dictated  by  this  external  interface.  However,  by  keep- 
ing the  logical  description  textually  distinct  from  that  of  the  representation,  we  shall  be  able  to 
retain  the  cleanliness  of  the  logical  description. 

The  above  separation  principle  is  reflected  in  the  Green  language  by  a clear  textual  separation 
between  the  declaration  of  the  logical  properties  of  data  and  the  specification  of  their  represen- 
tational properties.  The  latter,  called  a representation  specification,  must  appear  after  the  declara- 
tion of  the  logical  properties.  Representation  specifications  are  themselves  grouped.  Hence  the 
parts  of  a program  that  might  be  hardware  specific  are  easy  to  identify. 


14.2  Types  and  Data  Representation 


In  a language  containing  strong  typing  facilities,  it  is  important  to  associate  representation 
specifications  with  types  rather  than  with  individual  ob,ects.  The  basic  reasons  are  simplicity  and 
uniformity.  To  associate  representation  specifications  with  individual  objects  could  mean  that 
these  specifications  have  to  be  duplicated  in  many  separate  declarations  and  it  might  therefore  be 
difficult  to  maintain  consistency,  especially  after  repeated  modification. 

Alternately  it  could  mean  that  representations  are  named  and  that  each  object  declaration  men- 
tions both  a type  name  and  a representation  name.  However  such  a solution  would  result  in  less 
readable  programs.  As  a consequence,  a simpler  solution  has  been  used  in  the  Green  language  and 
a representation  is  associated  with  a type. 

Associating  representation  with  type  localizes  this  specification  in  one  place.  The  specification  is 
then  implicitly  associated  with  all  objects  of  the  given  type  (constants,  variables,  formal 
parameters,  etc.). 

A further  advantage  of  this  approach  is  that,  while  each  type  has  some  representation,  the  user 
generally  does  not  need  to  be  concerned  with  it.  Accordingly,  user  defined  representation 
specifications  are  optional,  to  be  used  only  in  cases  where  some  external  requirements  must  be 
satisfied;  in  the  absence  of  such  a specification,  the  representation  is  determined  by  the  translator. 
Generally,  the  translator  will  choose  an  efficient  representation,  but  no  particular  default  is 
guaranteed.  Thus,  even  a slight  change  to  a declaration  may  result  in  a completely  different 
representation. 

Representation  specifications  may  be  more  or  less  complete;  in  some  cases  they  fully  specify 
some  mapping,  while  in  other  cases  such  as  packing  specifications  they  merely  provide  the 
translator  with  criteria  for  the  choice  of  a representation. 
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14.3  Multiple  Representation*  and  Change*  of  Representation 


When  a program  has  to  deal  with  objects  existing  on  an  external  medium,  one  is  faced  with  the 
problem  of  multiple  representations.  For  example,  records  may  be  stored  in  a packed  form  on  a file, 
but  a program  may  require  rapid  access  to  the  record  components  when  the  information  is  proces- 
sed and  hence  may  require  an  unpacked  form.  This  is  a classic  situation  where  one  wants  two  dif- 
ferent representations  for  the  same  objects. 

Although  the  details  of  the  alternate  representations  are  not  part  of  the  logical  properties,  we  will 
show  with  the  following  example  that  the  knowledge  of  the  existence  of  alternate  representations 
is.  itself,  a logical  property. 


14.3.1  A Canonical  Example  for  Change*  of  Representation 


Consider  the  problem  of  converting  data  from  one  external  medium  into  a form  ready  to  be  output 
onto  another  external  medium.  Both  data  objects  belong  to  the  same  enumeration  type,  but  have 
different  representations,  each  of  which  is  fixed  by  the  outside  world.  The  following  program  frag- 
ment gives  a hypothetical  formulation  (not  following  the  syntax  of  the  Green  language)  for  the 
required  procedure: 

procedure  CONVERT  is 

— declarations  of  the  logical  properties: 

type  DAY  is  (MON,  TUE.  WED,  THU,  FRI,  SAT,  SUN); 

X,  Y : DAY; 


— representation  specifications  ( not  in  the  Green  syntax): 
representation  FORM^A  of  DAY  is 

(MON  =>  1,  TUE  =>  2.  WED  =>  3,  THU  =>  4,  FRI  =>  5,  SAT  =>  6.  SUN  =>  7); 
representation  FORM_B  of  DAY  is 

(MON  =>  0.  TUE  =>  1,  WED  =>  2,  THU  =>  3,  FRI  =>  4,  SAT  =>  5,  SUN  =>  6); 
tor  X use  representation  F0RM_A; 
for  Y use  representation  F0RM_B; 

— end  of  representation  specifications  (in  hypothetical  syntax ) 
begin 

Y :=  X; 
end  CONVERT; 

In  trying  to  establish  the  correctness  of  the  above  procedure,  one  finds  that  the  information  con- 
tained in  the  logical  declarations  of  X and  Y do  not  suffice.  It  can  only  be  concluded  that  X and  Y 
are  of  type  DAY.  To  complete  the  correctness  proof  (that  conversion  is  properly  effected),  one  is 
forced  to  look  into  the  representation  specifications,  and  hence  to  violate  the  separation  principle 
mentioned  earlier.  We  are  thus  lead  to  the  conclusion  that  any  attempt  to  hide  the  existence  of 
multiple  representations  at  the  logical  level  ultimately  leads  to  a violation  of  the  separation  princi- 
ple. 
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14.3.2  One  Type,  On*  Representation  Principle 


As  argued  earlier,  since  the  concept  of  type  is  in  the  language,  it  is  natural  and  desirable  to  use 
type  as  a carrier  for  representation  The  view  adopted  in  the  Green  language  is  thus  that  a unique 
representation  corresponds  to  each  type.  Th  s results  in  a significant  simplification,  since  the  user 
does  not  have  to  think  in  terms  of  multiple  representations  for  a single  type. 


The  solution  to  the  problem  of  multiple  representation  is  based  on  the  declaration  of  types  bv 
means  of  derived  type  definitions.  For  example,  a type  B can  be  derived  from  a type  A by  declaring 


typ*  B it  new  A; 


Since  8 derives  its  characteristics  from  A,  both  types  have  the  same  characteristics,  for  example 
the  same  components.  However  they  are  distinct  types  and  it  is  hence  possible  to  specify  different 
representations  for  A and  for  B Change  of  representrtion  can  be  achieved  by  explicit  conversion 
etween  objects  of  type  A and  B since  such  conversions  are  defined  for  derived  types.  The  derived 
type  definition  has  the  effect  of  creating  a type  with  the  same  characteristics  as  another  type 
without  rewriting  its  entire  description  (since  that  would  define  a distinct  type  for  which  no  conver- 
sions are  possible). 


Note : 


The  one  type,  one  representation  principle  must  be  understood  in  terms  of  the  knowledge  that  the 
user  has  from  the  existence  (as  opposed  to  the  detailsl  of  a representation.  It  means  that  if  the  user 
explicit. y specifies  the  representation  of  a type,  he  may  only  specify  one  representation. 

However,  in  cases  where  the  representation  is  implicitly  selected  by  the  translator,  it  may  use  dif- 
ferent internal  representations  in  different  contexts  with  full  knowledge  of  the  consequences  of  its 
choices. 


14.3.3  Explicit  Type  Conversion  and  Change  of  Representation 


The  problem  of  change  of  representation  is  now  straightforward;  it  can  be  expressed  as  an  explicit 
type  conversion  between  two  logically  equivalent  types.  A type  conversion  is  specified  by  the  use 
of  a qualified  expression,  where  the  qualifier  is  the  name  of  the  type  to  which  the  expression  is  to 
be  conv  'rted,  for  example 

Y :=  EXTERN/ LDAY(X); 

in  the  conversion  problem  presented  earlier.  This  may  be  properly  expressed  in  the  Green  languaqe 
as  follows:  w y 
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procedure  CONVERT  is 

--  declaration  of  the  logical  properties: 

type  DAY  is  (MON,  TUE,  WED,  THU,  FRI,  SAT,  SUN): 
fyp®  EXTERNAl — DAY  is  new  DAY;  — a derived  type 

X : DAY; 

Y ; EXTERNAL.DAY; 

— representation  specifications  for  the  two  types: 

for  DAY  use 

(MON  =>  1,  TUE  =>  2,  WED  =>  3,  THU  > 4,  FRI  =>  5,  SAT  =>  6,  SUN  =>  7) 
for  EXTERNAl DAY  use 

(MON  =>  0.  TUE  =>  1.  WED  =>  2.  THU  =>  3,  FRI  =>  4,  SAT  = n 5,  SUN  =>  6), 

— end  of  representation  specifications 


begin  • 

Y :=  EXTERNAl DAY(X); 

end  CONVERT; 

The  correctness  of  this  procedure  can  now  be  established  without  violation  of  the  separation  prin- 
ciple First  we  have  to  show  that  the  program  is  correct  given  the  definition  of  X and  Y:  Initially  X 
. contains  a value  of  type  DAY;  the  expression  EXTERN AL_DAY(X)  is  legal  since  the  type,  EXTER- 
NAL-DAY is  derived  from  the  type  DAY  and  it  converts  X into  a value  of  type  EXTERNAL_DAY 
that  is  assigned  to  Y.  Second,  it  must  be  shown  that  the  representation  given  for  DAY  and  EXTFR- 
NAL_DAY  are  correct. 

The  same  simple  strategy  would  be  used  in  the  previously  mentioned  case  of  conversions  of  a 
record  structure  between  a packed  representation  and  an  unpacked  representation: 

type  OBJECT  is 
record 

— declaration  of  the  components  of  objects 

end  record; 

type  EXTERNAL-OBJECT  is  new  OBJECT;  - a distinct  type  derived  from  OBJECT 

X : OBJECT; 

Y ; EXTERNAL-OBJECT; 

for  EXTERN  *' -OBJECT  use  pecking; 


X :=  OBJECT(Y);  — unpack 

Y :=  EXTERNAL_OBJECT(X);  - pack 
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14.3.4  implementation  of  Representation  Changes 


Although  they  are  limited  to  types  which  are  conformable,  since  they  are  declared  as  logically 
equivalent,  type  conversions  may  in  some  cases  be  very  costly.  As  an  example  consider  a record 
type  with  variant  parts. 

type  V is 
record 

D : constant  BOOLEAN: 
case  0 of 

when  TRUE  =>  I : INTEGER 
when  FALSE  =>  R : REAL; 

end  case: 

end  record; 

type  W is  new  V; 

X : V: 

Y : W. 

for  V use  ... 
for  W use  ... 

X :=  V(Y); 

The  implementation  of  the  assignment  X ;=  V(Y);  cannot  be  achieved  as  simply  as  for  a normal 
record  assignment.  Rather  it  must  be  done  0,1  a field  by  field  basis  equivalent  to  the  following 
program  (apart  from  the  restriction  on  assignment  to  the  discriminant); 

X.D  ;=  Y.D;  — would  be  illegal  if  written  so 
case  X.D  of 

when  TRUE  =>  X.l  :=  Y.l; 
when  FALSE  =>  X.R  :=  Y.R; 

end  case; 

Although  complex,  it  is  within  the  state  of  the  art  to  produce  such  code  but  it  is  nevertheless  costly 
on  some  computers  (note  that  there  might  be  variants  within  variants).  Expressing  such  changes  of 
representations  as  explicit  conversions  warns  the  user  about  the  potentially  high  cost  of  such 
operations. 


14.4  Presentation  of  the  Data  Representation  Facility 


All  representation  specifications  have  the  same  general  syntact'c  form  in  the  Green  language.  The 
data  type  for  which  the  representation  is  given  is  surrounded  by  the  reserved  words  Vor  and  uee  as 
follows 

for  TYPE_NAME  use 
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For  example,  to  specify  a packed  representation  for  boolean  matrices,  one  would  write: 


type  BIT_MAP  is  array  (1  ..  100,  1 ..  100)  of  BOOLEAN; 
for  BIT_MAP  uee  packing: 

In  general,  for  array  and  record  types  where  one  would  like  to  minimize  storage,  but  for  which  the 
exact  mapping  is  immaterial,  it  is  possible  to  use  this  packing  specification.  Consider  the  case  of  an 
aray  of  a given  component  type.  For  each  component  the  translator  must  allocate  a storage  field 
with  a certain  number  of  bits.  There  may  also  be  some  gaps  (i.e.  unused  bit  fields)  between  two 
consecutive  components.  The  effect  of  packing  is  to  instruct  the  translator  to  minimize  such  gaps 
On  the  other  hand,  if  the  component  type  is  itself  an  array  or  record  type  it  may  also  contain  inter- 
nal gaps.  These  are  unaffected  by  the  packing  specification  given  for  the  array  type.  Minimization 
of  such  gaps  could  be  achieved  by  a prior  packing  specification  given  for  the  component  type  itself 

It  is  also  possible  to  use  a length  specification  to  specify  the  size  that  should  be  used  for  objects  of 
a given  type.  This  may  be  used  for  cases  in  which  a user  wants  to  optimize  access  time  to  fre- 
quently used  record  components,  without  having  to  specify  the  entire  record  layout. 

For  task  names  a length  specification  can  be  used  to  provide  an  upper  bound  for  the  storage 
needed  by  oi.e  task;  for  example,  if  the  task  contains  recursive  procedure  calls,  dynamic  arrays,  or 
local  access  types.  Note  that  such  a specification  does  not  dictate  the  actual  allocation  strategy 
used  for  tasks;  it  could  still  be  dynamic  (at  initiation  time)  or  static  (at  the  time  of  elaboration  of 
the  task  declaration).  It  only  supplies  information  to  this  allocation  strategy.  (Note  that  this  is  one 
case  where  the  representation  specification  is  applied  to  something  other  than  a type  name). 

For  access  types,  a length  specification  provides  the  size  of  the  storage  space  to  be  reserved 
statically  when  elaborating  the  access  type  declaration.  This  space  is  used  for  the  collection  of 
dynamically  created  records  associi-ted  with  a given  access  type.  The  collection  associated  with  an 
access  type  which  has  such  a length  specification  is  allocated  statically  at  scope  entry  time  exactly 
as  for  an  array.  Hence  it  permits  the  use  of  access  types  with  their  notational  and  efficiency  advan- 
tages (component  selection  is  cheaper  than  array  indexing  for  arrays  of  records)  without  paying  the 
potential  costs  of  a more  dynamic  allocation  strategy  such  as  heap  storage  management. 

To  define  sufficient  storage  space  there  is  a need  to  know  the  storage  size  necessary  for  one  ele- 
ment. For  an  access  type  T,  the  attribute  T'SIZE  can  be  used  for  tnis  purpose.  For  example  the  size 
of  a collection  of  dynamic  records  LIST_ELEM  large  enough  to  contain  approximately  2000 
records  can  be  expressed  as  follows: 

type  LIST.ELEM  is  access 
record 

VALUr  : INTEGER; 

SUCC  : LIST.ELEM, 

PRED  : LIST_ELEM; 

end  record; 


for  LIST_ELEM  use  2000«LIST_ELEM'SIZE; 
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The  number  of  dynamic  records  is  only  known  as  an  approximation  since  the  storage  allocator  may 
need  some  space  and  also  because  records  with  variant  parts  may  have  different  lengths. 

A length  specification  can  also  be  used  to  achieve  a biased  representation  for  an  integer  type  For 
example,  if  we  have  a type  ranging  from  10_000  to  10_255,  any  value  of  this  type  can  be 
represented  in  only  8 bits.  Specifying  a length  of  8 bits  for  this  type  will  result  in  the  translator 
using  a biased  representation.  For  example: 


type  SKEWED  is  new  INTEGER 
for  SKEWED  use  8; 


range  10_000  ..  10_255; 


14.4.1  Enumeration  Type  Representations 


An  enumeration  type  representation  is  used  to  specify  the  mapping  from  the  elements  of  an 
enumeration  type  to  the  specific  internal  codes  used  to  represent  the  elements. 

The  mapping  is  specified  using  an  array  aggregate  in  which  the  elements  of  the  type  are 
enumerated  one  by  one.  The  type  of  such  an  aggregate  is  a one-dimensional  array  whose  element 
type  is  integer  and  whose  index  range  is  the  enumeration  type  itself.  For  example,  consider  the 
program  that  generates  object  code  for  a given  machine  and  in  which  the  operation  codes  for  the 
machine  are  defined  as  an  enumeration  type.  It  is  necessary  to  map  the  enumeration  values  into 
actual  operation  codes  and  this  can  be  achieved  as  follows: 

type  MIX_CODE  is  (ADD,  SUB.  MUL,  LDA,  STA,  STZ); 

for  MIX_CODE  use 

(ADD  =>  1,  SUB  =>  2,  MUL  =>  3,  LDA  =>  8.  STA  =>  24,  STZ  =>  33); 

In  this  example  the  array  aggregate  is  of  type 
array  (MIX_CODE)  of  INTEGER 

Obviously  all  enumeration  values  must  be  provided  with  distinct  integer  codes  and  their  codes 
must  be  known  at  translation  time.  In  addition,  in  order  to  get  an  efficient  implementation  for 
ordered  enumeration  types,  the  internal  codes  must  follow  the  same  ordering  as  the  enumeration 
values.  The  order  relations  are  then  known  through  the  internal  codes,  and  there  is  no  need  for  the 
translator  to  generate  tables  that  contain  the  order  relation. 

As  illustrated  above,  the  specified  internal  codes  do  not  need  to  be  contiguous  integers.  We  dis- 
cuss the  implications  of  this  issue  later  in  section  14.5. 


14.4.2  Record  Type  Representations 


Record  type  representations  allow  the  specification  of  a storage  layout  for  records.  This  represen- 
tation is  specified  by  giving  the  order  of  record  components,  their  position,  and  their  size  in 
machine  dependent  terms  All  the  expressions  defining  such  a specification  must  be  static  expres- 
sions; their  values  must  be  known  at  translation  time.  A global  alignment  clause  can  also  be 
specified. 

Storage  Units : 

The  storage  unit  is  a configuration  dependent  quantity  representing  the  machine's  quantum  of 
storage.  Its  value  can  be  accessed  through  the  standard  attribute  SYSTEMSTORAGE_UNIT  and  is 
the  unit  of  addressing  implicitly  used  to  denote  the  position  of  a component. 

Bit  Range : 

A bit  range  is  used  to  specify  both  the  storage  size  in  bits  and  the  position  of  the  first  bit  of  a com- 
ponent inside  a storage  unit.  The  two  expressions  in  the  range  represent  the  positions  of  the  first 
and  last  bit  respectively.  This  implies  that  the  bit  ordering  inside  a storage  unit  be  known  to  the 
user.  Such  an  ordering  is  configuration  dependent  and  thus  implementation  defined.  Thu  logically 
first  bit  of  a storage  unit  is  always  numbered  0.  For  example  the  specification 

SYSTEM.MASK  at  0 range  0 . 7; 

means  that  the  component  SYSTEM_MASK  needs  8 bits  of  storage  starting  from  the  beginning  of 
the  storage  unit.  The  storage  size  specified  for  a component  must  of  course  be  large  enough  for  the 
component.  The  translator  shall  check  that  it  is  compatible  with  the  minimum  needed  for  the 
representation  of  values  of  the  component  type. 

Bit  numbering  extends  through  consecutive  storage  units;  thus  the  specification 
PROTECTION_KEY  at  0 ranga  8 ..  11; 
is  legal  even  if  the  storage  unit  has  eight  bits  on  the  machine  considered. 

At  Clause : 

The  at  clause  specifies  the  position  of  a component  by  giving  the  position  of  the  storage  unit 
relative  to  which  the  bit  range  is  counted.  This  position  is  itself  relative  to  the  first  storage  unit  of 
the  record,  which  is  numbered  0.  For  example, 

TRACK  at  2 ranga  0 ..  15; 

means  that  the  component  TRACK  occupies  16  bits  starting  from  bit  0 of  the  storage  unit 
numbered  2.  If  the  value  of  SYSTEM'STORAGEJJNIT  were  8,  the  last  bit  of  TRACK  would  actual- 
ly be  bit  7 in  the  adjacent  storage  unit  numbered  3.  Overlapping  components  are  only  allowed 
when  they  belong  to  distinct  variants.  Overlap  of  record  components  is  not  allowed  within  a 
variant,  and  the  translator  will  check  that  this  is  not  the  case.  For  example  the  overlap  of  LINE_- 
COUNT  and  CYLINDER  in  the  following  specification  is  lepil  since  they  belong  to  different 
variants: 


i 
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type  PERIPHERAL  !• 

record 

UNIT  constant  (PRINTER.  DISK.  DRUM); 
cm*  UNIT  o « 

whan  PRINTER  <=> 

LINE_COUNT  : INTEGER  range  1 ..  50: 
whan  others  »> 

CYLINDER  : CYLINDER_INDEX, 

TRACK  : TRACK_NUMBER; 

and  caaa: 
and  racord 


--  assuming  SYSTEM  STORAGE-UNIT  - 8 bits 

lor  PERIPHERAL  uaa 
racord  at  mod'  4. 

UNIT  at  0 range  0 ..  7; 

LINE.  COUNT  at  1 range  0 ..  7; 

CYLINDER  at  1 range  0 ..  7. 

TRACK  at  2 range  0 ..  15: 

and  racord; 

When  the  record  representation  specification  is  incomplete,  t.e.  it  does  not  specify  the  layout  for  all 
components,  freedom  is  left  to  the  translator  to  map  the  unspecified  components  in  a way  which  is 
consistent  with  the  logic  of  the  record  declaration.  Translators  shall  produce  object  listings  of 
record  mappings  upon  request. 

Alignment  Clause. 

When  it  is  important  that  the  object  of  a given  record  type  be  allocated  on  a given  storage  boun- 
dary. this  can  be  specified  by  means  of  an  alignment  clause.  The  alignment  is  expressed  as  a 
number  of  storage  units,  and  all  addresses  at  which  the  objects  are  allocated  must  be  exact  multi- 
ples of  the  specified  number  of  storage  units  (the  address  modulo  the  alignment  express:on  must 
be  zero). 


14.4.3  Address  Specifications 


An  address  specification  can  oe  used  to  force  the  storage  space  of  a given  variable  to  be  allocated 
at  an  address  specified  in  storage  units. 

for  PSD  use  at  16#40; 

This  form  of  specification  can  also  be  used  for  specifying  the  address  of  the  code  of  a subprogram, 
or  to  link  an  interrupt  with  a given  entry  The  conventions  used  for  mapping  this  integer  on  a 
hardware  locution  are  implementation  dependent.  As  a consequence,  other  system  dependent 
information  can  be  derived  from  the  value  of  this  expression. 
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14.5  Enumeration  Types  with  Non -Contiguous  Representations 


The  specified  internal  codes  of  an  enumeration  type  do  not  need  to  have  contiguous  values.  This 
degree  of  generality  is  required,  if  character  types  are  to  be  represented  by  enumeration  types 
since  many  character  sets  have  non-contiguous  internal  values. 

We  next  discuss  the  implications  of  non-contiguous  representations  on  assignment  and  com- 
parison, indexing  and  case  selection,  and  finally  on  iteration. 


14.5.1  Assignment  and  Comparison  with  Non-Contiguous  Enumeration  Typas 


An  assignment  only  results  in  moving  a value  from  one  location  to  another,  and  thus  is  not 
influenced  by  the  non-contiguity  of  a representation.  Similarly,  non-contiguity  has  no  impact  on 
comparison. 


14.5.2  Indexing  and  Casa  Statements  with  Non-Contiguous  Enumeration  Typas 

The  simplest  way  to  treat  an  array  indexed  by  an  enumeration  type  having  a non-contiguous 
representation  is  to  implement  it  like  a normal  array,  and  leave  holes  (i.e.  unused  positions)  in  the 
storage  used  for  it.  No  conversion  is  then  needed  between  the  internal  code  and  the  real  index  to 
storage,  since  they  have  the  same  value.  In  a similar  way,  the  internal  jump  table  used  for  a case 
statement  may  have  holes. 

Note  that  no  problem  arises  when  such  arrays  are  passed  as  parameters  to  subprograms  since  the 
index  type  is  part  of  the  array  type  and  the  same  mapping  can  be  used  inside  and  outside  the  sub 
program. 

The  user  should  be  aware  of  the  hidden  storage  costs  involved.  This  is  certainly  preferable  to 
prohibiting  the  use  of  types  with  non-contiguous  representations  for  indexing  and  in  case  state- 
ments. If  we  consider  character  sets,  for  instance,  the  proportion  of  holes  remains  at  an  acceptable 
level. 


14.5.3  Iteration  Over  Non-Con  tig  uoue  Enumeration  Types 


We  are  faced  with  a more  severe  problem  when  a loop  parameter  ranges  over  the  values  of  a non- 
contiguous enumeration  type;  simply  incrementing  the  value  of  the  loop  parameter  by  a constant 
at  each  iteration  will  not  work  correctly  I To  keep  the  same  underlying  mechanism,  we  need  the 
notion  of  a characteristic  vector,  which  carries  the  information  on  the  internal  codes.  For  every 
such  loop,  the  translator  will  include  code  to  interrogate  the  characteristic  vector. 

This  mechanism  is  illustrated  by  the  following  example.  Consider  the  type  MIXED,  for  which  a non- 
contiguous representation  has  been  specified. 

type  MIXED  is  (A.  B,  C,  D); 

for  MIXED  use  (A  =>  30,  B =>  32,  C =>  33,  D =>  37); 
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A loop  statement  iterating  over  the  values  of  the  MIXED  type  can  be  written  as  follows: 

for  I in  MIXED  FIRST  ..  MIXED  LAST  loop 
PHI; 

end  loop: 

The  translator  will  produce  an  object  code  which  is  equivalent  to  the  following  text  (apart  from  typ- 
ing rules): 

PRESENT  constant  array  (30  ..  37)  of  BOOLEAN 

:=  (30  | 32  | 33  | 37  «>  TRUE,  others  «>  FALSE); 

for  I in  30  ..  37  loop 
if  PRESENT(I)  then 
P(l); 

end  if; 
end  loop; 

As  illustrated  above,  the  translation  involves  a characteristic  vector  (PRESENT)  which  is  used  to 
generate  the  integer  values  corresponding  to  the  enumeration  type  MIXED.  Thus  we  see  that 
iterating  over  such  types  is  possible,  but  involves  a small  extra  cost. 


14.5.4  Character  Types 


Character  types  are  a typical  example  of  enumeration  types  with  not  necessarily  contiguous 
representations.  The  predefined  character  type  CHARACTER  denoting  the  full  ASCII  character  set 
of  1 28  characters  is  contiguous  but  the  same  is  not  true  for  other  widely  used  character  sets  such 
as  EBCDIC  Such  character  sets  will  generally  be  defined  in  library  modules,  including  both  the 
character  type  declaration  and  the  associated  representation  specification.  It  may  be  convenient  to 
provide  such  a definition  in  two  steps.  For  example: 

type  CHAR  is  (enumeration  of  a//  EBCDIC  .characters): 

type  EBCDIC  Is  new  CHAR;  - same  characters  as  CHAR 

for  EBCDIC  use  ( codes  corresponding  to  .EBCDIC  characters ): 

A user  to  whom  the  internal  code  is  relevant  (e.g.  because  he  is  performing  input-output)  will 
de  Hare  objects  of  type  EBCDIC.  For  other  usages,  especially  if  such  characters  are  to  be  used  as 
indices,  in  case  statements  and  in  iterations,  the  user  might  prefer  to  use  the  type  CHAR.  Since  no 
representation  specification  is  given  for  this  type,  the  translator  will  adopt  a default  representation 
that  is  convenient  for  indexing  and  iteration.  Explicit  conversions  between  the  two  types  can  be 
performed  for  input-output. 
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14.6  Configuration  Specification  and  Environment  Enquiriaa 


To  generate  object  code,  some  machine  and  configuration  dependent  properties  such  as  the 
machine  model,  memory  size,  and  special  hardware  options  must  be  available  to  the  translator. 
Hence  specification  of  configuration  dependent  features  must  be  possible.  Typical  uses  of  such 
information  are  for  the  detection  of  resource  usage  overflow  and  the  generation  of  special  purpose 
instructions  for  the  target  machine 
\ 

Conversely,  programs  may  need  to  access  information  that  is  known  to  the  translator.  There  are 
numerous  uses  for  such  information.  A user  level  input-output  routine  may  need  to  invoke  alter- 
native algorithms  depending  upon  the  object  machine  configuration  (with  the  discrimination  being 
made  at  translation);  similarly,  it  may  need  to  know  the  size  of  the  storage  unit  for  the  object 
machine,  and  the  size  of  the  objects  transferred. 

The  approach  used  in  the  Green  language  is  to  have  pragmas  for  the  specification  of  information  to 
the  translator,  and  to  use  predefined  attributes  as  general  environment  enquiries  in  order  to  refer 
to  information  known  by  the  translator 


14.6.1  Pragmas 


Pragmas  serve  to  provide  the  translator  with  information  that  is  relevant  for  the  translation 
process.  This  information  does  not  affect  the  semantics  of  programs.  For  example  we  may  have 

pragma  SYSTEM(MULTICS); 
pragma  STORAGE_UNIT(36); 
pragma  INCLUDE(COMMON_TEXT): 
pragma  OPTIMIZE(SPACE). 
pragma  LIS  i (ON): 
pragma  PAGE; 

pragma  SUPPRESS(OVERFLOW); 

We  can  distinguish  two  main  categories  of  pragmas:  configuration  specifications  and  translator 
options  The  configuration  of  a given  object  machine  can  be  specified  for  a translation  unit  by  a list 
of  pragmas.  Among  them  there  will  generally  be  c > for  the  machine  architecture  model  SYSTEM 
ono  for  the  memory  size  MEMORY_SIZE,  and  one  for  the  size  of  storage  unit  STORAGE_UNIT 
This  category  can  also  include  pragmas  defining  special  hardware  options  device  configurations 
and  any  special  characteristics  of  an  operating  system. 

Translator  options  will  generally  include  time  or  space  optimiiation  a control  for  the  listing  of 
source  and  object  programs,  and  so  forth. 


14.6.2  Predefined  Attributes 


Predefined  attributes  may  be  viewed  as  the  interrogative  counterpart  of  pragmas  They  provide  an 
environment  enquiry  mechanism  which  can  be  used  to  obtain  configuration  dependent  informa- 
tion and  more  generally  other  information  known  by  the  translator  We  have  two  majoi  catr  lories 
of  environment  enquiries,  corresponding  to  the  two  main  categories  of  pragmas 

Configuration  characteristics  can  be  accessed  via  configuration  dependent  constants  expressed  as 
attributes  of  the  predefined  name  SYSTEM  For  example  we  have  SYSTEM  MEMORY_SIZE  for 
the  memory  size  and  SYSTEM  NAME  tor  the  machine  architecture  model 

The  translator  options  are  accessed  via  predefined  boolean  attributes  of  the  Predefined  name 
OPTION  for  example: 

OPTION  SPACE  TRUE  if  space  is  the  current  optimization  criterion 

The  mechanism  is  also  used  as  a general  environment  enquiry  mechanism  for  example  to  access 
•roporties  of  program  components  the  bounds  of  an  index  of  an  array,  the  address  of  an  ob|ecl  or 
nformation  about  a record  representation:  to  obtain  the  implemented  range  of  a program  compo 
nent;  to  read  the  systems  real  t me  clock  to  obtain  the  length  of  the  queue  associated  with  an 
entry,  etc. 

As  mentioned  in  the  section  on  lexical  issues  the  names  of  predefined  attributes  are  always 
preceded  by  an  apostrophe  As  a consequence  the  correspond*  *g  identifiers  are  not  reserved 
Some  typical  examples  are  given  below 


t ABLE  FIRST 
MATRIX  FIRST(2I 
OLD  PSW  ADDRESS 
X MASK  POSITION 
X MASK  FIRST  BIT 
X MASK  LAST  BIT 
INTEGER  SIZE 
REAL  RADIX 
REAL  EXPONENT_FIRST 
REAL  EXPONENT.LAST 
SYSTEM  CLOCK 
SYSTEM  STOR  GE.  UNIT 


--  the  first  index  of  TABLE 

the  first  index  ot  the  second  dimension  of  MATRIX 

the  address  in  storage  units  ot  OLD_PSW 

the  first  position  of  the  component  MASK  in  Xtat  clause) 

the  position  of  the  fust  hit  of  MASK 

the  position  of  the  last  bit  of  MASK 

the  implemented  size  ot  INTEGER  in  bits 

t j implemented  radix  ot  REAL 

the  implemented  lower  hound  and 

upper  bound  of  the  exponent  for  REAL 

- the  real  time  clock 

- the  number  of  bits  in  a storage  unit 


14.6.3  Configuration  Specification  and  Conditional  Compilation 

Sometimes  it  is  desirable  to  write  a program  in  which  portions  vary  according  to  the  object 
machine  configuration  Such  conditional  tianslation  can  be  achieved  by  conditional  statements 
selecting  among  alternative  program  fragments  For  example  a program  providing  different 
iigorithms  for  different  systems  may  appear  as  follows: 


I 

I 
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pragma  SYSTEMlMULTICS) 


caaa  SYSTEM  NAME  of 
when  TENEX  -> 

pan  specific  to  TENEX 
when  MULTICS  ■> 

pail  specific  to  MULTICS 
when  UYK20  | AYK 14 

pan  specific  to  these  systems 
when  VS_370  • n 

part  specific  to  VS_370 
end  caaa 


The  system  name  established  by  the  pragma  is  considered  as  an  enumeration  value  that  can  be 
tested  later  Since  the  system  name  is  known  at  translation  time,  a translator  may  decide  to 
optimize  the  case  statement  end  generate  only  the  code  corresponding  to  the  current  system 
name.  Thus  the  program  can  be  tailored  to  a given  machine 

This  facility  is  deliberately  primitive.  Conditional  translation  of  declarations  can  be  at  ieved  in  a 
limited  way  by  variant  record  Types  On  the  other  hand  no  general  mechanism  for  conditional 
translation  of  program  units  is  provided.  We  consider  such  mechanisms  tor  text  selection  to  belong 
to  the  domain  of  the  facilities  provided  by  the  support  tools  tor  the  language 


14.7  Interface  with  Other  Languages 


A limited  facility  for  machine  code  insertions  has  been  included  in  the  Green  language.  This  facility 
has  the  advantage  of  clearly  isolating  the  use  of  machine  language.  However  its  general  use  is 
heavier  than  direct  use  of  an  assembler. 

Each  machine  instruction  appears  as  a code  statement,  which  is  a record  aggregate  of  a record 
type  definmg  the  corresponding  instruction.  Sucn  record  definitions  will  generally  be  available  in  a 
library  package  for  each  machine.  The  library  package  must  also  contain  the  representation  of  the 
record  describing  the  machine  instruction  format.  These  code  statements  are  used  in  procedures 
which  must  contain  only  code  statements  and  are  included  inline 

The  following  example  illustrates  the  use  of  a set  system  mask  instruction  on  370  like  machines. 
This  example  shows  that  it  may  be  necessary  to  use  implementation  specific  predefined  attributes 
in  code  statements  such  as  M BASE  (the  base  register  used  for  Ml  and  M DISP  (the  displacement 
of  Ml 

M MASK 

procedure  SET  MASK  is 
pragma  INUNE: 

uaa  INSTRUCTIONS  .370:  - makes  visible  the  identifiers  SI-FORMAT  SSM  etc 

SI-FORMAT(CODE  -N  SSM  B M BASE  D ->  M DISP) 


Additional  implementation  specific  pragmas  may  be  needed  to  specify  the  register  and  linkage 
conventions  Obviously  such  pragmas  cannot  be  machine  independent:  the  only  order  that  may  be 
brought  by  a high  level  language  in  such  a matter  is  to  standardize  the  mechanism  by  which  such 
specifications  are  given  In  the  Green  language  this  mechanism  is  provided  by  pragmar  As  a final 
example  pragmas  can  also  be  used  to  specify  that  a subprogram  is  wiitten  in  another  language 

procedure  bAUSStA  in  out  MATRIX  X in  out  VECTOR  N INTEGER!  is 

begin 

pragma  INTERFACED OHTRAN! 

end 

In  this  example  a procedure  skeleton  is  written  in  Green  For  other  subprograms  it  has  the  effect  of 
specifying  the  calling  convention  in  Gieen  terms.  The  seguence  of  statements  is  limited  to  the 
INTERFACE  pragma,  informing  the  translate  about  the  corresponding  linkage  conventions  and 
also  to  expect  the  ob|ect  code  to  be  provided  later  (at  linkage  edition  timel  Of  course  translators 
may  impose  restrictions  on  the  form  of  parameters  allowed  Not  all  translators  need  piovide  such  a 
capability. 


14.8  Unsafe  Programming 


The  conversions  allowed  among  numeric  types  and  among  types  that  aie  derived  from  each  other 
are  safe  conversions  that  do  not  violate  the  rules  ot  type  checking 

Unsafe  type  conversions  can  be  achieved  in  any  language  that  permits  code  insertions  or  add'ess 
specifications.  Such  conversions  mav  tor  example  be  needed  it  a user  wants  to  define  his  own 
allocation  strategy  tor  access  types.  In  this  case  conversions  from  integer  to  access  values  are 
necessary  to  define  an  ALLOCATE  procedure  and  conversely  a FREE  procedure 

From  a programming  management  and  also  from  a maintainability  point  ot  view  it  is  desirable  :o 
provide  a standard  way  to  achieve  such  unsafe  conversions.  In  this  wav  parts  ot  a program  using 
such  dangerous  features  are  made  easier  to  identify  The  following  library  module  is  predefined  to 
that  ettect. 

package  UNSAFE  PROGRAMMING  I* 

generic ' type  S.  type  U 

function  UNSAFE  .CONVERSIONS  SI  return  T 
end  UNSAFE  PROGRAMMING 

A program  unit  using  unsafe  type  conveisions  must  include  this  package  in  its  visibility  list  Hence 
its  visibility  restriction  will  appear  as 

restricted!  , UNSAFE  .PROGRAMMING.  ...) 

In  addition,  it  must  instantiate  the  function  UNSAFE„CONVERSION  for  the  types  for  which  the 
convention  is  desired  For  example 

function  UNSAFE  I N'T'  TO  UST  Is  new  UNSAFE  CONVERStONONTEGER  LIST  IIFM' 

The  programming  environment  may  be  able  to  control  ami  restrict  the  programs  that  are  allowed 
to  get  access  to  the  package  UNSAFE  PROGRAMMING 
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15.  Input-Output 

* v .• 


1 5. 1 Introduction 


Input-output  is  recognised  as  a source  of  difficulty  tor  programmers.  It  often  accounts  for  a large 
part  of  a programming  system  and  generally  is  either  neglected  in  a language  formulation  (e.g. 
Algol  60.  Coral  66)  or  causes  many  special  and  often  confusing  features  to  be  built  into  a language 
(e  g.  Input-Output  lists  and  formats  in  Fortran  format  variables  in  Algol  68).  Even  Pascal  uses 
special  procedure  structures  (with  optional  file  parameters  and  a special  field  width  separator) 
available  only  in  the  predefined  input-output  procedures 

Even  more  importantly,  the  needs  for  application  level  input-output  may  vary  greatly  between  clas- 
ses of  applications.  For  example,  file  manipulation,  batch  processing  line  and  page  layout,  interac- 
tive input,  and  non-character  processing  pose  significantly  different  problems.  An  attempt  to  build 
in  special  features  to  cover  the  range  of  input-output  applications  would  mean  that  every  user  and 
every  translator  would  be  forced  to  take  account  of  this  additional  complexity. 

A major  design  goal  in  the  Green  language  was  therefore  to  provide  the  ability  to  develop  a rich  set 
of  input-output  facilities  without  additional  language  constructs  In  this  chapter  we  demonstrate 
that  this  ability  has  been  achieved.  Input-output  packages  can  bt  written  without  resort  to  special 
features.  Given  this  ability,  it  will  be  possible  for  user  groups  to  develop  and  standardize 
specialized  input-output  packages  corresponding  to  major  application  classes. 

The  language  nevertheless  provides  a recommended  set  of  input-output  operations  in  compliance 
with  the  Steelman  requirements  and  in  recognition  of  the  fact  that  the  existence  of  such  a set  is 
essential  tor  portability 

Three  standard  input-output  packages  are  given  in  the  language  definition.  The  generic  package 
INPUT_OUTPUT  defines  a general  set  of  user  level  input-output  operations.  Additional  operations 
for  text  input  output  are  defined  in  the  standard  package  TEXT_I0.  Finally  the  package 
LOW_LEVEL_IO  defines  the  form  of  the  operations  used  for  dealing  with  low  level  input-output. 
The  design  of  these  packages  is  discussed  in  this  chapter.  We  conclude  by  a discussion  of  the 
problems  involved  in  writing  an  input-output  package  within  the  language  itself. 


15.2  General  User  Level  Input-Output 


The  user  level  input-output  operations  are  defined  by  the  package  INPUT_OUTPUT.  These  opera- 
tions are  applicable  to  files  containing  elements  of  a single  type.  After  discussing  the  conventions 
used  to  designate  external  files,  devices,  and  internal  files  we  discuss  the  facilities  offered  by  the 
package. 
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1 5.2.1  Designation  of  External  files 


Input  output  operations  effect  itata  exchanges  between  a processor  running  on  behalf  of  the  user 
program  and  some  peripheral  device  Traditionally  the  notion  of  file,  seen  as  a repository  of  infor 
mation  is  often  distinguished  from  that  <. : a device  However  the  logical  behavior  of  a program 
does  not  depend  on  the  source  or  destination  of  data  as  long  as  the  data  represents  the  desired 
information  Por  example  it  is  perfectly  reasonable  to  interface  the  same  program  with  a disk  file  at 
one  time  and  with  a terminal  at  another  time 

In  consequence  the  conventions  used  to  designate  the  target  of  an  input-output  operation  should 
not  necessarily  distinguish  between  file  names,  device  names  volume  names,  etc.  In  addition 
these  conventions  should  not  conflict  with  those  of  any  system  on  which  the  language  is 
implemented  This  dictates  a flexible  approach 

We  define  an  externa/  file  as  any  component  of  a computer  system  that  can  be  designated  as  the 
target  of  input-output  operations  Ihe  name  of  an  external  file  is  written  as  a string  and  its 
interpretation  is  system  dependent  In  some  implementations  the  name  may  contain  additional 
control  information 


15.2.2  Designation  of  Internal  Files 


An  external  file  as  defined  above  is  an  entity  which  can  produce  or  absorb  data.  The  lifetime  of  an 
external  file  is  not  tied  to  a particular  program.  For  example  an  external  file  can  be  created  by  one 
program  and  be  later  deleted  by  another  program 

In  contrast  within  a program  performing  an  input  output  operation  an  object  called  an  internal  file 
lor  just  a file)  is  used  to  refer  to  the  external  file.  Such  files  are  variables  of  the  encapsulated  types 
IN_FILE  OUT_FILE  and  INOUT_FILE.  These  types  and  the  set  of  operations  applicable  to  them 
are  defined  in  the  package  INPUT_OUTPUT 

The  most  salient  feature  of  a file  is  that  it  is  associated  with  an  element  type:  on  any  particular  file 
input  and  output  operations  are  done  in  terms  of  values  of  that  type.  A file  is  also  permanently 
associated  with  a mode:  there  are  files  on  which  only  input  is  possible  (IN_FILE).  files  on  which 
only  output  is  possible  (OUT_FILE)  and  files  on  which  both  input  and  output  are  possible 
IINOUT.FILE). 

Note  that  the  mod^  is  a property  of  a file  as  an  object  manipulated  by  the  program  and  not  a 
property  of  a particular  external  file  Such  restrictions  may  be  placed  on  given  devices  or  data  sets 
by  a given  system  but  defming  them  is  not  within  the  realm  of  the  language,  nor  should  it  be 
Indeed,  different  systems  may  have  defined  arbitrarily  sophisticated  protection  schemes  to  control 
access  to  resources  The  state  of  the  art  in  the  design  of  such  schemes  is  constantly  evolving  and 
standard  primitives  of  a language  should  not  interfere  with  this  evolution. 

Access  to  certain  external  files  may  nevertheless  be  limited  because  of  such  protection  schemes, 
or  because  of  other  physical  limitations.  Two  exception  conditions  correspond  to  these  limitations. 
FILE_NAME_ERROR  is  raised  when  a CREATE  or  OPEN  cannot  be  performed  and  FILE_USE_ER- 
ROR  is  raised  if  an  operation  cannot  be  performed  on  an  open  file  because  of  physical  or  logical 
limitations 

The  mode  of  a program  file  is  given  by  the  declaration  of  a file  variable  since  it  is  implicitly 
associated  with  the  possible  types  (IN  FILE  OUT  FILE  or  INOUT.FILE' 
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1 5.2.3  Overview  of  Hi*  Operation* 


A file  can  be  dynamically  associated  with  a specified  external  file.  The  association  ia  established  by 
a CREATE  or  OPEN  operation,  and  severed  by  a CLOSE  or  DELETE  operation.  A file  that  is 
associated  with  an  external  file  is  said  to  be  open.  The  status  of  a file  can  be  interrogated  by  the 
function  IS_OPEN.  The  operations  CREATE  and  OPEN  can  only  be  performed  on  files  that  are  not 
open.  All  other  operations  must  be  performed  on  open  files 

The  name  of  the  external  file  associated  with  an  open  file  is  given  by  the  function  NAME.  The  total 
number  of  elements  of  the  file  ia  given  by  SIZE.  SIZE  is  applicable  to  external  files  of  any  kind:  for  a 
data  set  this  can  be  computed  from  the  storage  size  of  the  data  set.  For  devices  that  perform 
stream  input  or  output.  SIZE  corresponds  to  the  number  of  elements  read  or  written  on  that  file  by 
the  program. 

Once  a file  is  open,  a particular  element  is  recognized  as  the  target  of  the  next  input  or  output 
operation.  The  position  of  this  component  in  the  file  is  given  by  the  function  NEXT.  The  first  com- 
ponent of  a file  corresponds  to  the  position  1.  The  value  returned  by  NEXT  is  automatically 
incremented  by  a successful  input  or  output  operation  It  can  also  be  altered  explicitly  by  the 
procedure  SET_NEXT.  Certain  restrictions  on  an  external  file  may  place  limitations  on  the  use  of 
SET_NEXT.  or  prohibit  it  entirely.  For  example,  it  may  be  impossible  to  back  up  input  from  a ter- 
minal. or  to  set  it  outside  a certain  range  on  a card-reader.  Note  however  that  in  the  absence  of 
other  limitations,  it  is  always  possible  to  set  the  next  position  to  a value  larger  than  the  file  size,  or 
to  a non-positive  value.  An  exception  would  be  raised  only  upon  a subsequent  input  or  output 
operation.  Unless  forbidden  by  the  nature  of  the  external  file,  writing  an  element  at  a position 
beyond  the  current  file  size  has  the  effect  of  extending  the  size. 

The  next  position  is  always  incremented  after  a successful  read  or  write,  independently  of  the 
mode  of  a file;  thus  all  files  can  be  accessed  either  sequentially  or  (if  SET_NEXT  is  allowed)  ran- 
domly. In  particular,  the  user  can  conveniently  perform  a sequential  scan  of  part  of  a file,  then 
move  to  another  part  and  again  scan  the  file  sequentially. 

Actual  input  and  output  operations  are  performed  by  the  READ  and  WRITE  primitives.  READ  is  not 

defined  for  OUT_FILE,  and  WRITE  is  not  defined  for  IN FILE.  If  further  restrictions  prohibit  the 

operation,  a FILE_USE_ERROR  exception  is  raised.  If  an  attempt  is  made  to  READ  past  the  end  of 
a file,  an  END_OF_FILE  exception  is  raised.  Explicit  testing  of  an  end  of  file  condition  can  be  easily 
done  by 

NEXT(F)  > SIZEIF) 

Note  that  the  user  level  input-output  facilities  are  provided  without  any  reference  to  a particular 
buffering  scheme.  On  a simple  system  a READ  or  WRITE  operation  could  correspond  to  the 
appropriate  physical  input  or  output  operation  without  any  buffering.  When  needed,  a buffering 
strategy  can  be  defined  by  manipulating  files  whose  components  are  arrays.  For  example,  we  may 
have 


type  BUFFER  is  array  (1  ..  512)  of  INTEGER, 
package  BUFFEREDJO  is  now  INPUT_OUTPUT(BUFFER>: 
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15.3  Taut  Inp'  t-Output 


Several  input  and  output  operations  involve  character  strings.  These  operations  are  particularly 
common  in  programs  that  receive  input  from,  or  produce  output  for,  a human  operator.  Such  use  is 
sufficiently  widespead  to  justify  provision  of  a more  sophisticated  set  of  primitives  than  those 
available  for  general  files  of  characters. 

Assuming  a predefined  character  set,  it  must  at  least  be  possible  for  the  user  to  request  input  or 
output  of  values  of  any  primitive  type  represented  as  strings  of  characters.  Such  an  effect  can  of 
course  be  achieved  in  two  steps:  in  the  case  of  input,  first  read  a string  of  characters,  and  then  con- 
vert it  to  an  internal  value;  in  the  case  of  output,  first  convert  a value  to  a string,  and  then  write  out 
each  character  of  the  string.  Conversion  procedures  are  actually  piovided  for  each  scalar  type  of 
the  language  by  the  predefined  attributes  REP  and  VAL.  It  would  however  be  unacceptable  to 
force  the  user  who  wants  to  output,  say,  an  integer  X to  write: 

declare 

S : STRING  :=  INTEGER  REP(X); 

begin 

for  I in  1 ..  S LENGTH  loop 
WRITE  (S(l)>; 

end  loop; 
end; 

Therefore  it  is  necessary  to  predefine  a standard  function  (say  PUT)  which  does  at  least  that.  The 
need  for  procedures  that  combine  input  or  output  with  string  conversion  is  even  more  acute  when 
reading  values,  since  strings  of  a particular  form  must  be  recognized  before  being  converted. 

The  operations  defined  in  the  package  TEXT_IO  consider  a text  as  a stream  of  characters.  Lines  are 
particular  logical  units  of  arbitrary  length.  This  view  corresponds  to  interactive  systems  practice.  In 
addition,  a simple  convention  allows  the  user  to  fix  the  line  length,  and  to  use  the  same  primitives 
for  fixed  format  input  or  output. 

consistent  with  the  design  of  all  user  level  input-output,  the  text  input-output  facilities  are  defined 
entirely  within  the  language.  No  special  language  construct  (e  g.  formats,  pictures)  are  introduced. 
In  particular,  no  special  syntax  rule  is  added.  Input  and  output  facilities  are  defined  for  all  scalar 
types,  including  user  defined  enumeration  and  fixed  point  types. 

In  order  to  minimize  the  number  of  names  that  must  be  remembered  by  a user,  the  basic  opera- 
tions for  text  input-output  appear  as  overloaded  subprograms  called  GET  and  PUT. 

In  order  to  simplify  the  writing  of  input-output  operations,  default  parameters  have  been  used  for 
specifying  format  information.  In  addition  the  package  defines  a standard  input  file  and  a standard 
output  file,  both  opened  during  the  elaboration  of  the  package  body.  Each  PUT  or  GET  operation  is 
defined  in  two  overloaded  versions:  one  where  an  explicit  file  must  be  specified,  and  one  where  it 
is  not  specified.  The  latter  versions  operate  on  the  default  input  file  (for  GET)  and  the  default  out- 
put file  (for  PUT).  The  initial  default  files  can  be  accessed  explicitly  by  the  functions  STANDAR- 
D_INPUT  and  STANDARD_OUTPUT.  The  user  may  change  the  default  input  and  output  files  with 
the  procedures  SETJNPUT  and  SET_OUTPUT.  Since  STANDARDJNPUT  and  STANDARD_OUT- 
PUT  are  functions,  the  user  cannot  close  them  (since  CLOSE  and  DELETE  expect  an  out 
parameter). 

Note  that  the  default  parameter  mechanism  has  not  been  used  for  the  definition  of  the  alternative 
version?  of  GET  and  PUT  (for  an  explicit  or  for  a default  file)  since  such  a formulation  would  not 
permit  changing  the  default  file. 
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15.3.1  Characters,  Llnaa.  and  Columns 


Tha  package  TEXT-IO  is  defined  for  streams  of  characters  of  the  ASCII  character  set  This 
character  set  includes  a set  of  control  characters,  and  is  especially  adapted  to  free  format  text  A 
consequence  is  that  the  notion  of  line  need  not  be  defined  in  terms  of  a fixed  length  Indeed,  a line 
can  be  viewed  as  any  sequence  of  characters  enclosed  between  two  line  marks  A line  mark  can  be 
the  beginning  or  the  end  of  the  tile  or  an  implementation  defined  sequence  of  characters  (for 
•example  the  sequence  carriage  return,  line  teed).  Line  marks  can  be  denoted  by  the  predefined  str 
mg  NEWLINE. 

The  notion  of  current  line  can  be  associated  with  the  number  of  line  marks  that  have  been  input  or 
output.  The  effect  of  SET-LINE  on  input  will  thus  be  to  read  forward  or  backward  over  the 
appropriate  number  of  line  marks  (equal  to  the  difference  Lietween  the  target  line  and  the  current 
line  If  the  target  line  number  is  larger,  or  otherwise  to  the  difference  between  the  current  line  and 
the  target  line,  plus  one)  This  latter  case  may  be  prohibited  It  not.  the  backward  read  is  followed 
by  a foiwaid  read  over  the  last  line  mark,  to  get  to  the  beginning  of  the  line  On  output,  the  effect 
of  SET  LINE  is  device  dependent:  it  may  either  have  the  same  effect  as  on  input  (e  g with  disk 
files),  or  output  the  appropriate  number  of  line  marks  (e  g on  a terminal) 

Note  that  SET  LINE  always  has  the  implicit  effect  of  setting  the  current  column  to  the  beginning 
of  the  line.  This  decision  (rather  than  to  set  the  current  line  independently  of  the  current  column) 
corresponds  to  a more  common  usage.  In  addition  setting  the  current  line  alone  would  not  be 
clearly  defined  with  variable  length  lines,  since  the  current  column  may  end  up  being  off  the  end  of 
the  current  line 

The  notion  of  column  is  associated  with  the  position  of  a character  from  the  beginning  of  a line 
The  effect  of  special  control  characters  is  defined  so  as  to  preserve  as  much  as  possible  the  iden 
tity  between  the  column  number  and  the  position  of  a character  on  a printed  line  The  primitive 
SET  COL  can  be  used  to  skip  to  a certain  position  on  a line.  On  some  output  devices,  it  may  have 
the  effect  of  spaces,  or  backspaces 

Although  these  primitives  are  defined  for  variable  length  lines.  It  is  fairly  easy  to  apply  them  to  fix 
ed  length  lines  The  user  can  first  set  the  line  length  on  a particular  file  to  a value  of  his  choice 
When  this  is  done,  line  marks  are  implicitly  inserted  after  the  printable  character  in  column  L. 
where  L is  the  line  length  With  these  luyout  primitives,  the  user  can  define  procedures  such  as 

procedure  EJFCTI  FILE  OUT  FILE;  N INTEGER  : I)  Is 

begin 

SET  LINEtFILE.  I INE(FILE)  f N): 

end 

procedure  EJECTtN  INTEGER  1)  la 

begin 

SET  LINE(STANOARl)  OUTPUT.  LINEIS1 ANDARU  OUTPUT)  t N) 

end; 

procedure  SPACESlFILE  OUT_FILE,  N : INTEGER  1)  is 

begin 

SET  COUFILE,  COLIFILE)  ♦ N); 

end 

procedure  SKIP!  FILE  : IN-FILE;  N : INTEGER  : 1 ) is 

begin 

SET  COLIFILE  COUFILE)  ♦ N); 

end; 
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15.3.2  Taxi  Processing  and  Formatting 


The  string  representation  of  an  internal  value  is  defined  in  accordance  with  the  lexical  representa 
tion  of  literals  in  the  Green  language.  Note  that  it  may  be  necessary,  upon  input,  to  look  two 
characters  ahead  to  determine  the  end  of  a lexical  unit.  For  example,  if  the  input  text  contains  the 
string 

12 83ERGS 

then,  when  a GET  is  issued  for  a floating  point  value,  it  is  necessary  to  see  the  R of  ERGS  to  deter 
mine  the  result  of  GET,  as  the  E could  be  the  beginning  of  an  exponent. 

On  the  other  hand,  with  the  convention  to  output  a space  in  front  of  any  numeric  or  enumeration 
value,  it  is  possible  to  have  a one  to  one  mapping  between  the  operations  needed  to  write  a text, 
and  those  needed  to  read  it. 

The  GET  and  PUT  operations  can  be  used  for  both  free  and  fixed  format  texts  With  free  format  the 
user  is  primarily  interested  in  outputting  a value  without  extraneous  characters,  whereas  in  fixed 
format,  the  goal  is  to  place  the  value  at  a specified  position  on  a line.  The  default  parameter 
mechanism  of  the  Green  language  can  be  used  to  achieve  both  effects  in  a single  definition,  by 
providing  a field  width  argument  whose  default  value  (0)  will  cause  the  minimum  number  of 
characters  to  be  used  Thus,  omission  of  the  width  parameter  provides  free  format  output  whereas 
fixed  format  can  be  obtained  when  it  is  given.  This  can  be  contrasted  with  the  Pascal  convention 
which  provides  an  implementation  defined  default  field  width,  thus  making  it  awkward  to  output 
small  numbers  in  free  format 

In  the  case  of  fixed  and  floating  point  types,  the  number  of  digits  appearing  after  the  decimal  point 
(the  length  of  the  mantissa)  is  by  default  the  minimum  number  of  digits  consistent  with  the 
accuracy  specified  for  the  type. 

The  PUT  procedure  can  be  defined  for  all  scalar  types  in  terms  of  the  predefined  attribute  REP  the 
procedure  PUT  for  strings,  and  two  functions,  LEFT_PAD  and  RIGHT_PAD.  defined  by. 

function  LEFT_PAD(S  : STRING  ; N : INTEGER)  return  STRING  Is 
N.BLANKS  : constant  INTEGER  :=  N - SLENGTH; 

T : STRING1 1 ..  N. BLANKS)  (others  =>  " "); 
begin 

if  N BLANKS  v 0 then 
return  S: 

else 

return  T S S: 
end  if: 

end  IEFT_PAD: 

function  RIGHT_PAD(S  : STRING  ; N INTEGER)  return  STRING  is 
N_ BLANKS  : constant  INTEGER  :»  N - S LENGTH 
T : STRING!  1 N_BLANKS>  (others  =>  ’ 
begin 

if  N_ BLANKS  v-  O then 
return  S; 

else 

return  S & T: 
end  If 

end  RIGHT_PAD; 

For  example,  the  integer  form  of  PUT  can  be  defined  as 


1 
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procedure  PUTIFILE  : OUT.FILE;  ITEM  : INTEGER;  WIDTH  ; INTEGER  0)  Is 
S : STRING  .=  INTEGER  REP(ITEM); 

U COL(FILE)  + MAXIS'LENGTH.  WIDTH)  >~  LINE.LENGTHIFILE)  thon 
SET_UNE(FILE.  LINEIFILE)  + 1); 
sMf  COUFILE)  /=  1 thon 
PUT(“  "I: 

end  if; 

PUTIFILE.  LEFT.PADIS,  WIDTH)); 

end; 

In  the  case  of  fixed  point  types,  the  internal  representation  is  dependent  on  the  declared  range  and 
delta.  Therefore,  in  contrast  to  floating  point  typei,  no  predefined  input-output  function  can  be 
given  without  knowledge  of  the  type.  A similar  case  exists  for  enumeration  types  since  the  cor- 
responding enumeration  literals  are  not  known  in  the  TEXTJO  package.  The  solution  taken 
provides  PUT  and  GET  procedures  in  generic  packages  that  can  be  instantiated  by  the  user. 
Default  generic  parameters  reduce  the  complexity  of  the  instantiation  by  automatically  providing 
the  formatting  functions  REP  and  VAl. 

Consider  the  following  example 

type  FRAC  is  delta  0.005  range  -1000.0  ..  1000.0: 
type  COLOR  la  (RED.  YELLOW,  GREEN.  OLUE); 

package  FRACJO  is  new  FIXEDJO(FRAC): 
package  COLOFUO  is  new  ENUMJOICOLOR); 

declare 

uee  FRACJO.  COLORJO; 

F : FRAC  :=  1.990: 

C : COLOR  :=  RED; 
begin 

PUTIC);  PUT(F); 

PUT(NEWLINE); 

PUTIC,  6);  PUTIF.  12,  5); 

end; 


In  the  output  below,  note  that  an  enumeration  value  is  left  justified  whereas  a number  is  right 
justified: 

RED  1.990 

RED  1.99000 

The  default  mantissa  for  FRAC  is  determintd  upon  instantiation  by  the  exp.*ssion 
DELTA^REP' LENGTH  - 2 
where 

DELTA_REP  = FRAC  REPIFRAC  DELTA  - INTEGERIFRAC  DFLTAII 

Since  FRAC'DELTA  is  0.005,  DELTA_REP  will  be  "0.005"  and  the  expression  thus  evaluates  to 
the  desired  3 digits.  The  complexity  of  the  expression  is  needed  to  cope  with  deltas  greater  than  1 . 
in  which  case  the  integer  part  must  be  wholly  represented. 

Although  the  primitives  defined  by  INPUT_OUTPUT  are  not  given  explicitly  in  the  TEXTJO 
package  specification,  those  taking  IN_FILE  and  OUT_FILE  parameters  are  inherited  by  the 
Je.'/ed  types  declared  in  TEXTJO. 
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1 5.3.3  An  Example 


ssL-jxtssx  cskiss  Ksrr.rr.sr 

procedure  LISTING  is 
uae  TEXT_lO; 

package  INT_IO  Is  new  INPUT_JUTPUT|INTEGER) 

Ao'nJPr1!1  : 0UTJ:,LE  " '•«  TEXT  file 
ARIICLFS  ; IN„FILE;  - also  TEXT 
INVENTORY  : INTJO.IN  FILE 
CH  : CHARACTER 
VALUE  : INTEGER 


POS 


INTEGER. 


" recognised  as  line  printer 


begin 

OPENIPRINTOUT.  "prtr") 

OPENIARTICLES  aiticles) 

INT  IO.OPENUNVENTORY.  "inventory"). 

SET -L:NE_LENGTH(PRINTOUT,  30), 

PUTr°nicUr[<PR,NTOUT,:  " printout  is  now  d8,Bul»  output  file 
SET_COL(PRINTOUT  20), 

PUTCinventory " & NFWLINE  & NEWLINE) 

loop 

begin 

INTJO  READONVENTORY  VALUE) 

POS  1; 

loop 

GETIARTICLES,  CH); 

exit  when  CH  * ' 

If  POS  < 20  then 
PUT(CH); 

POS  :=  POS  + 1; 

end  If; 
end  loop. 

SET_COL( PRINTOUT.  20): 

PUT(VALUE,  9);  - fills  line  entirely  (new  line  will  be  automatic) 


exception 

when  END_OF_FILE  s 
CLOSE!  PRINTOUT); 

CLOSE!  ARTICLES); 

INT_IO.CLOSE|  INVENTORY); 
SET_OUTPUT(STANDARD  OUTPUT) 
exit 


when  others  *> 

PUT(STAN0AR0  OUTPUT  "printout  error  at  line") 
PUTISTANDARD  .OUTPUT.  LINE(PRINTOUT)) 
PUT(STANDARD_OUTPUT.  NEWLINE) 
PUT(NEWLINE);  - on  printout 


end  loop; 

end  LISTING; 
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15.4  Low  Laval  Input-Output 


r 

r 


\ 

Low  level  input-output  facilities  are  especially  needed  in  embedded  computer  systems,  since 
signal  processing  and  interaction  with  non-standard  peripheral  devices  are  common.  Clearly,  major 
system  dependencies  cannot  be  avoided  in  this  area.  At  best  the  language  can  provide  a set  of 
standard  calling  conventions  for  dealing  directly  with  peripherals.  The  specific  device  and  data 
description  cannot  however  be  given. 

Interaction  with  peripheral  devices  involves  three  forms  of  actions',  starting  an  operation  on  a 
device,  interrogating  the  status  of  a device,  and  waiting  for  completion  of  an  operation.  Facilities  to 
deal  with  this  latter  case  are  provided  by  the  entry  mechanism  and  interrupt  specification.  The  first 
two  cases,  however,  constitute  requests  from  the  program.  For  these,  two  procedure  names  are 
'iitroduced:  SEND_CONTROL  to  start  an  operation,  and  RECEIVE_CONTROL  to  interrogate  the 
status.  Both  take  two  arguments:  DEVICE  identifies  a particular  peripheral  device,  and  DATA  cor- 
responds to  the  information  that  should  be  exchanged  with  the  device  (hence  DATA  is  an  In  out 
parameter). 

For  the  definition  of  such  procedures,  we  are  faced  with  two  problems:  efficiency  and  generality. 

Efficiency  dictates  that  an  operation  which  norma  ly  requires  a small  number  of  machine  instruc- 
tions should  not  be  surrounded  by  lengthy  checks.  t*his  could  be  achieved  by  making  the  low  level 
primitives  built-in  to  a given  compiler.  However  generality  requires  the  ability  to  write  the 
appropriate  SEND_CONTROL  and  RECEIVE.CONTROI  operations  whenever  a new  device  is 
added  to  the  system,  without  forcing  a recompilation  of  the  translator.  Hence  these  operations 
cannot  be  built-in. 

In  order  to  satisfy  these  apparently  conflicting  goals,  subprogram  overloading  and  code  statements 
can  be  used.  As  many  device  types  should  be  introduced  as  required  by  the  interfacing  conven- 
tions of  the  system.  Similarly,  for  each  device  type,  appropriate  data  types  should  be  introduced. 

For  each  meaningful  combination  of  device  type  and  data  type,  overloaded  definitions  of  SEND_- 
CONTROL  and  RECEIVE_CONTROL  can  be  given,  and  the  corresponding  subprogram  bodies  may 
use  appropriate  code  statements.  The  general  form  of  the  package  LOW_LEVELJO  is  as  follows 

package  LOW_LEVEL_IO  Is 

— declarations  of  different  device-types 

— declarations  of  different  dete-types 

— declarations  of  overloaded  procedures  for  these  types: 

procedure  SEND_CONTROL  (DEVICE  : device  type,  DATA  : In  out  data  type): 

procedure  RECEIVE—CONTROL  (DEVICE  : device  type,  DATA  in  out  data  type): 
end  LOW  LEVEL-IO: 

Thus  if  a user  must  introduce  a new  device,  then  the  appropriate  types  and  procedures  can  be 
defined  independently  of  existing  ones:  this  only  requires  a recompilation  of  the  package 
LOW_LEVEL_IO. 


’ " 5 Writing  an  Input-Output  Package  in  the  Language 


The  motivations  for  defining  user  level  input-output  within  the  language  itself  were  given  in  the 
introduction.  Defining  input-output  operations  is  not  inherently  difficult.  On  the  other  hand  defining 
file  types  and  their  operations  by  the  normal  mechanisms  of  type  definitions  and  without  sacrific- 
ing reliability  and  efficiency  is  a major  challenge. 


Mott  languages  so  far  have  avoiued  the  difficulty  by  having  built-in  file  types  We  believe  this 
approach  to  be  wrong,  since  the  problem  raised  by  the  definition  of  specialized  application  data 
types  will  be  of  the  same  order  of  difficulty  as  those  raised  by  files.  Thus  the  inability  to  define  files 
within  the  language  would  be  a symptom  that  should  not  be  neglected  by  the  language  designer. 

The  solution  taken  defines  files  as  restricted  private  types  one  type  for  each  file  mode  This 
enables  us  to  enforce  control  over  file  manipulation  in  the  language  itself  Since  the  type  is  a static 
property,  it  is  possible  to  check  at  compilation  time  that  a READ  operation  is  not  performed  on  an 
OUT_FILE.  similarly  that  a WRITE  operation  is  not  performed  on  an  IN_FILE. 

The  alternative  approach  would  have  been  to  associate  a mode  with  a file  when  this  file  is 
assigned  a value  by  an  OPEN  or  CREATE  operation.  In  that  case  each  READ  operation  would  have 
had  to  start  with  the  check 

If  MODEIFILE)  - OUTPUT  then 
rates  INVALID_MODE: 
end  M: 

Note  that  this  possibility  of  compile  time  checking  of  mode  restrictions  can  be  achieved  at  no  extra 
complexity  for  the  user  because  of  the  overloading  facility.  Primitives  can  be  defined  for  different 
file  types  that  have  the  same  name,  so  that  the  number  of  distinct  primitives  to  be  remembered  by 
the  user  is  not  increased. 

Additional  power  is  provided  for  the  control  of  open  and  closed  files.  CREATE  and  OPEN  should 
not  be  applied  to  files  that  are  already  open,  for  fear  of  destroying  any  path  to  an  open  file.  A check 
on  this  can  be  performed  by  passing  the  file  as  an  in  out  parameter  to  CREATE  or  OPEN,  which  can 
perform  the  test 

N IS_OPEN(FILE)  then 
raise  FILE_OPEN_ERROR; 

end  M: 

Clearly,  this  would  lead  to  problems  with  uninitialized  variables  on  the  first  CREATE  or  OPEN  on  a 
file,  but  the  ability  to  provide  a default  initialization  of  record  components  allows  us  to  solve  this 
problem  by  a declaration  of  the  form 

genericltype  ELEMENT _T\PE> 
package  INPUT-OUTPUT  Is 

restricted  type  IN_FILE  is  private: 
restricted  type  OUT.FILE  is  private, 
restricted  type  INOUT.FILE  Is  private 

P,*NCLFIlE  : constant  INTEGER  0: 
type  BASIC-FILE  is 
record 

FILE.  INDEX  : INTEGER  NO-FILE; 

end 

type  IN-FILE  is  new  BASIC_FiLE; 
type  OUT-FILE  is  new  BASIC-FILE. 

*yi~  IN  OUT  .FILE  Is  new  BASIC.FILE: 
end  INPUT-OUTPUT 


16  10 


Thus  with  the  declarations 

F : IN-FILE: 

G : IN_FILt; 

the  two  files  are  initialized  and  the  creation  check  can  be  performed  Similarly  since  the  iiles  are 
passed  as  in  out  parameters  to  CLOSE  and  OELETE.  these  operations  can  reset  the  internal  value 
to  the  value  NO_FILE  corresponding  to  a closed  file  Note  also  that  it  may  be  essential  for  the 
package  to  ensure  that  file  names  are  not  lost.  This  could  happen  if  the  user  were  allowed  to 
assign  file  variables  such  as  F and  G.  but  this  is  prohibited  by  the  fact  that  IN_FILE  is  a restricted 
type. 

Another  important  aspect  of  the  languege  for  the  definition  of  input-output  is  the  ability  to 
parameterize  a package  and  the  enclosed  entities  (such  as  file  types)  by  a generic  clause  This 
facility  permits  the  definition  of  as  many  file  types  as  needed.  For  example  the  declarations 

pookags  INT-IO  Is  new  INPUT-OUTPUT(INTEGER); 
package  REALIO  is  new  INPUT_OUTPUT(REAL): 

define  complete  instantiations  of  the  package  INPUT_OUTPUT  for  the  corresponding  element 
types.  Consequently  the  file  variables  INT_FILE  and  REAL-FILE  in  the  following  declarations  r»  far 
to  two  distinct  file  types: 

INT.FILE  : INT_IO.IN_FILE; 

REAL-FILE  : REAL_IO.»N_FILE; 

Another  example  of  use  of  the  generic  facility  is  for  the  definition  of  input-output  for  enumeration 
types.  The  corresponding  package  has  the  form 

generic!  type  ENUM_TYPE; 

function  REPIX  : ENUM-TYPE)  return  STRING  Is  ENUM-TYPE  REP. 
function  VALIX  : STRING)  return  ENUM-TYPE  is  ENUM-TYPE  VAL) 

package  ENUM-IO  is 

procedure  PUTIFILE  : OUT_FILE; 

ITEM  : ENUM_TYPE: 

WIDTH  : INTEGER  :=  0); 


When  instantiating  such  a package  one  can  take  advantage  of  the  default  parameters  and  specify 
for  example 

package  COLOR-IO  is  new  ENUM-IO  (COIOR): 

Within  the  package  body,  the  body  of  the  procedure  PUT  can  be  expressed  in  terms  of  the  PUT 
function  available  for  strings 

procedure  PUT(FILE:  OUT-FILE;  ITEM:  ENUM.TYPE:  WIDTH:  INTEGER  :=  0)  is 
S : STRING  :=  REP(ITEM); 

tnjln 

--  check  column,  etc. 

PUTIFILE.  RIGHT-PADIS.  WIDTH)); 

and; 
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All  read  and  writ*  operations  can  be  mapped  onto  a more  primitive  package  dealing  with  bit  str- 
ings The  basic  read  and  write  operations  take  as  argument  a file  (for  example  of  the  type  BASIC. 
FILE  defined  above),  an  address  expressed  as  a number  of  storage  units,  and  a site  expressed  in 
bits.  As  a result,  a READ  operation  gets  the  appropriate  number  of  bits  from  the  designated  file, 
and  stores  them  starting  at  the  indicated  address.  Similarly.  WRITE  copies  the  appropriate  number 
of  bits  starting  at  the  indicated  address  onto  the  designated  file.  The  predefined  attributes 
ADDRESS  and  SIZE  can  be  used  to  express  the  typed  form  of  READ  and  WRITE  procedures  in 
terms  of  the  basic  (untyped)  form.  For  example  WRITE  could  call  a more  basic  procedure 
BASIC-WRITE  as  follows 

BASIC_WRITE(BASIC_FllE(FltE).  ITEM  ADDRESS.  ITEM  SIZE): 

Two  limitations  of  this  procedural  approach  to  input-output  should  be  mentioned  here.  First  the 
language  does  not  have  any  concept  equivalent  to  the  straightening  of  Algol  68.  If  straightening 
were  provided  a procedure  such  as  PUT  (which  is  defined  for  the  type  INTEGER)  would  bo 
automatically  extended  (by  iteration)  to  arrays  of  integers.  Similarly  if  PUT  is  defined  for  the  types 
of  the  components  of  the  record,  it  would  also  be  defined  for  the  record  type  itself.  The  second 
limitation  concerns  parameter  lists.  It  is  traditional  to  perform  several  output  operations  with  a 
single  orris'  but  this  is  not  permitted  by  a strictly  procedural  form.  Conceivably  one  could  use 
another  separator  (say  //  I to  permit  multiple  argument  lists  for  a procedure: 

PUTCX  - - //  X //  -Y  = " //  Y|;  - not  in  Green 

For  simplicity  neither  straightening  nor  mult.ple  parameter  lists  have  been  retained  in  Green.  The 
choice  of  short  identifiers  reduces  the  inconvenience  of  the  procedural  form: 

PUTCX  * -):  PUT(XI:  PUTCY  = I;  PUT(Y): 

In  conclusion  we  summarise  the  features  of  the  language  that  are  especially  useful  for  defining  the 
standard  input  output  package: 

• generic  packages 

• explicit  generic  instantiation 

• default  parameters  (both  for  procedures  and  for  generic  packages) 

• overloading 

• restricted  types 

• exceptions 

• default  record  initialisation 

Additional  features,  such  as  the  use  clause  and  the  inheritance  of  type  properties  have  been  used 
in  the  text  input-output  package. 
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